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Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 

@ Dynamisch optimierender Objektcode-Ubersetzer zur Architekturemulation und dynamisches optirnierendes 
Objektcode-Ubersetzungsverfahren 

@ Optirnierendes Objektcode-Ubersetzungssystem sowie 
Verfahren zur Durchfuhrung einer dynamischen Kompi- 
lierung und Ubersetzung eines Ziel-Objektcodes auf ei- 
nem Quell en-Betriebssystem, wahrend die Optimierung 
vorgenommen wird. Die Kompilierung und Optimierung 
des Zielcodes werden dynamisch in Echtzeit ausgefuhrt. 
Ein Kompilierer fuhrt eine Analyse und Optimierungen 
durch, welche die Emulation gegenuber einer auf einer 
Schablone basierenden Ubersetzung und Interpretation 
verbesern, so dafc ein Hostprozessor, der Instruktionen 
hoherer Ordnung, wie 32 Bit-lnstruktionen, verarbeitet, 
einen Zielprozessor emulieren kann, der Instruktionen 
niedrigerer Ordnung, wie 16 Bit- und 8 Bit-lnstruktionen, 
verarbeitet. Der optimierende Objektcode-Ubersetzer er- 
fordert keine Kenntnis eines statischen Programmflufc- 
graphen oder von Speicherzellen vor der Laufzeit. Ferner 
erfordert der optimierende Objektcode-Ubersetzer keine 
Kenntnis des Orts aller Verbindungspunkte in den Ziel- 
Objektcode vor der Ausfuhrung. Wahrend der Program- 
mausfuhrung zeichnet ein Ubersetzer Verzweigungsope- 
rationen auf. Die Protokol lie rung von Informationen iden- 
tifiziert Instruktionen und Instruktionsverbindungspunkte. 
Wenn eine Anzahl von Malen, die eine Verzweigungsope- 
ration ausgefuhrt wird, eine Schwelle uberschreitet, wird 
dasZiel der Verzweigung ein Startpara meter fur die Kom- 
pilierung, und Codeteile zwischen Start pa ramtern wer- 
den als Segmente definiert. Ein Segment kann unvoll- 
standig sein, wodurch eine Modifikation oder ... 
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Beschreibung 

HINTERGRUND DER ERFINDUNG 

S Die vorliegende Erfindung beziehl sich auf die Technik von Objektcode-Ubersetzern, die auf einem Hostverarbei- 
lungssystem operieren, uni ein zweites Betriebssyslera zu emulieren. Insbesondere belrifft die vorliegende Erfindung die 
Technik dynamischer Objektcode-Ubersetzer, die eine Analyse und Berechnung eines Original-Objektcode-Instrukti- 
onssatzes in Echtzeit wahrend der Ausfuhrung auf einem Hostprozessor, der einen Hostprozessor-Objektcode-Instrukli- 
onssaiz aufweist, durchfuhren. 

10 Auf deni Gebiet von Objektcode-Ubersetzern ist es notwendig, einen Objeklcode, der fur einen Computer entwickelt 
wurde, auf einem anderen Computer mil einer unterschiedlichen Compulerarchitektur zu konvertieren. Konvertierungs- 
verfahren fiir einen derartigen Objektcode enLhalten ein herkommliches Verfahren, das als "stalisches Objektcode- Kon- 
vertierungsverfahren" bezeichnet wird, und bei dem Tnstruktionsanweisungen vor der Ausfuhrung zuerst. in einen Ob- 
jektcode einer zweiten Archilektur konvertieri werden. Ein zweites Verfahren ist ein "dynamisches Objekt code-Konver- 

15 lierungs verfahren", bei dem ein erster Objektcode in einen zweiten Objektcode wahrend der Ausfuhrung von Instruktio- 
nen konverliert wird. 

In der Technik stauscher Objektcode-Kon vertierungsverfahren wird die Ausfuhrungszeit von der fur die Konvertie- 
rung erforderlichen Zeit nicht beeinfluBt. Die physische GroBe des konvertierten Objektcodes wird jedoch bei der Aus- 
fuhrung der stalischen Objektcode- KonverUerung groB. Mit anderen Worten ninuntbeim statischen Objektcode-Kon ver- 

20 tierungs verfahren eine Anzahl von Betriebsschritten im konvertierten Objektcode unweigerlich zu. Folglich entsteht in- 
sofem ein Problem, als sich die Leistung des konvertierten Objektcodes verschlechtert, und es zu Ineffizienzen kommt. 

Andererseits wird beim dynamischen Objektcode-Konvertierungs verfahren die GroBe des konvertierten Objektcodes 
relativ klein im Vergleich zum statischen konvertierten Objektcode. Das herkommliche dynamische Objektcode-Kon- 
vertierungsverfahren weist jedoch insofem ein Problem auf, als alle Objekte, einschlieBlich selten verwendeter Objekte, 

25 konvertiert werden. Mit anderen Worten kann das herkommliche dynamische Objektcode-Konvertiemngsverfahren Ob- 
jekte, die mehrere Male ausgefiihri werden, nicht efficient erkennen, und dadurch nimml die Zeit, die fur die Konvertie- 
rung des Original-Objcktcodcs crfordcrlich ist, auf Kostcn der Efnzicnz zu. 

KURZFA S SUNG DER ERFINDUNG 

DemgemaB ist es ein Objekt der voriiegenden Erfindung, einen Objektcode-Ubersetzer vorzusehen, der die bekannten 
Probleme eliminiert, wahrend er eine dynamische Optimierung des ubersetzten Objektcodes vorsieht. 

Es ist ein weiteres Objekt der voriiegenden Erfindung, ein Hauptprogramm zu profilieren, bis ein Kornpilierer das 
Kompilieren vollendet hat, wobei dieses Profil vom Kornpilierer zum Kompilieren und Optinueren des Programrns ver- 
35 wendetwird. 

Es ist noch ein weiteres Objekt der voriiegenden Erfindung, wahrend der dynamischen Optimierung und Kompilie- 
rung vom nicht-ubersetzten Code zum ubersetzten zu springen. 

Es ist noch ein weiteres Objekt der voriiegenden Erfindung, einen dynamischen optimierenden Objektcode-Ubersetzer 
mit einer Software-Ruckkopplung vorzusehen, der die Differenz zwischen einer Anzahl von Ubersetzungsanforderun- 
40 gen, die an den Kornpilierer gesendet werden, und einer Anzahl vollendeter Obersetzungen berechnet. 

Es ist noch ein weiteres Objekt der voriiegenden Erfindung, eine dynamische Ubersetzung eines Computerprogramms 
in einer Maschinensprache in eine andere Maschinensprache vorzusehen, wahrend das Programm lauft. 

Femer ist ein Objekt der voriiegenden Erfindung, einen dynamischen Objektcode-Ubersetzer vorzusehen, der Seg- 
mente zur Ubersetzung aus einer Vielzahl von Startparametern bestimmt, die Verzweigungen in einem Quellen-Objekt- 
45 code entsprechen. 

Die Objekte der voriiegenden Erfindung werden durch ein Computerarchitektur-Emulationssystem erreicht, welches 
eine Quellen-Computerarchitektur auf einer Ziel-Computerarchitektur emuliert, mit einem Interpreuerer zum individu- 
ellen Ubersetzen eines Quellen-Objektcodes in einen entsprechenden ubersetzten Objektcode und zum Bestimnien einer 
Anzahl von Ausfuhrungen von Verzweigungsinstruktionen im Quellen-Objektcode; und einem Kornpilierer zum Grup- 
50 pieren von Instruktionen des Quellen-Objektcodes in ein Segment, wenn eine Anzahl von Ausfuhrungen einer entspre- 
chenden Verzweigungsinstruktion eine Schweilenanzahl uberschreitet, und zum dynamischen Kompilieren des Seg- 
ments. 

Femer werden die Objekte der voriiegenden Erfindung durch ein Computerarchitektur-Emulationssystem erreicht, 
welches eine Quellen-Computerarchitektur auf einem Ziel-Computerarchitektursystem emuliert, mit einer Vielzahl von 

55 Interpretierem zum individuellen Ubersetzen eines Quellen-Objektcodes in einen entsprechenden ubersetzten Objekt- 
code, wobei jeder der Vielzahl von Interpretierem Quellen-Objektcode- Verzweigungsinfbrmationen in Echtzeit proti- 
liert, wahrend er Ubersetzte Objektccde-Instruktionen ausfuhrt; und einem Kornpilierer zum Gruppieren von Quellen- 
Objektcode-Instruktionen von irgendeinem der Vielzahl von Interpretierem in Segmente auf der Basis entsprechender 
Verzweigungsinstruktionen im Quellen-Objektcode und zum dynamischen Kompilieren der Segmente des Quellen-Ob- 

60 jektcodes, wenn die entsprechende Verzweigungsinstruktion groBer ist als eine Schweilenanzahl. 

Noch weitere Objekte der voriiegenden Erfindung werden durch ein Computerarchitektur-Emulationssystem erreicht, 
das eine Quellen-Computerarchitektur auf einem Ziel-Computerarchitektursystem emuliert, mit einem Interpretierer 
zum individuellen Ubersetzen eines Quellen-Objektcodes in einen entsprechenden ubersetzten Objektcode, wobei der 
Interpretierer Verzweigungsinstruktionen des Quellen-Objektcodes durch das Speichem einer Anzahl von Ausfuhrungen 

65 fiir jede Verzweigungsinstruktion und Vergleichen der Anzahl von Ausfuhrungen mit einer Schweilenanzahl profiliert, so 
daB Verzweigungsinstruktionen, welche die Schweilenanzahl uberschreiten, Startparameter sind; und einem Kornpilierer 
zum Gruppieren der Quellen-Objektcode-Instruktionen in Segmente auf der Basis der Startparameter und dynamischen 
Kompilieren der Segmente des Quellen-Objektcodes wahrend der t Jbersetzung und Profilierung durch den Interpretierer. 

o 
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Zusatzliche Objekle dcr vorliefBin Erfindung werden durch ein Mehraufgabcn-cl^Hterarchilcktur-Kmulaiions- 

sysiem crreicht, welches eine QueHcn-Compuierarchitekiur auf einer Mehraufgaben-Ziel-Computerarchitektur emulicri, 
mil einer Interpret iereraufgabe zuin individuellen Ubersetzen eines Quellen-Objektcodcs in einen enlsprechendcn uber- 
setzten Objektcode und zum Besummen einer Anzahi von Ausfiihrungen von Verzweigungsinstruktionen im Quellen- 
Objeklcode; und einer Kompiliereraufgabe, die mil dein Interpretierer auf der Mehraufgaben-Ziel-Computerarchiiektur 
operierl, zum Gruppieren von Inslrukiioncn des Quellcn-Objektcodes in ein Segment, wenn eine Anzahi von Ausfiihrun- 
gen einer entsprechenden Verzweigungsinstruktion eine Schweilenanzahl uberschreitet, und zum dynamischen Kompi- 
Lieren des Segments. 

KURZE BESCHREIBUNG DER ZEICHNUNGEN 

Diese und andere Objekte und Vorteile der vorliegenden Erfindung gehen aus der folgenden Beschreibung der bevor- 
zugten Ausfuhrungsformen in Verbindung mit den beigeschlossenen Zeichnungen hervor und werden dadurcb besser 

verstandlich, wobei: ■ _ L c , 

Fig. 1 ein Blockbild einer hoheren Architektur eines OOCT-Systems gemaB einer bevorzugten Ausfuhrungsforni der 

vorliegenden Erfindung ist; 

Fig. 2 ein FluBdiagramm ist, das Hauptkomponenten einer optimierenden Objektcode-Ubersetzung zusammen mit ei- 
nem SteuerfluB zur Kompilierung eines Abschnitts eines Originalcodes veranschauhcht; 

Fig. 3 ein FluBdiagramm ist, das den SteuerfluB in einer optimierenden Objektcode-Ubersetzung wahrend der norma- 
len Ausfuhrung veranschauiicht; 

Fig. 4 eine schematische Darsleilung ist, die einen OOC:T-Puffer fur eine Einstellung von Variablen veranschauhcht; 

Fig. 5a, 5b und 5c schematische Darstellungen sind, welche die Struktur einer UbersetzungstabeUe veranschau lichen; 

Fig. 6 ein Blockbild eines Interpret ierers zum Einspringen in ein Segment und Verlassen desselben ist; 

Fig. 7 ein Blockbild eines Kompilierungsverfahrens ist, urn ein Segment zu schaffen, urn das Segment durch einen In- 
terpretierer erreichbar zu machen, urn alte Segmente unerreichbar zu machen, und urn alte Segmente zu loschen; 

Fig. 8 ein Blockbild isl, das eine Struktur eines Verzweigungsdalensatzes bzw. engl. BRANCH_JRECORD veran- 
schauiicht; o 

Fig. 9 eine schematische Darstellung ist, welche eine Struktur eines Verzweigungsprotokolls als Teil einer groben 
Hash-Tabelle veranschauiicht, die BRANCH_RECORDs speichert; 

Fig. 10 eine schematische Darstellung ist, welche eine Struktur eines Ll-Cache veranschauiicht, der em zweidimen- 
sionales Array von BRANCH_L1 .RECORDS darstellt; 

Fig. 11 eine schematische Darstellung ist, die ein Verfahren zur Ausfuhrung des Betriebs des Ll-Cache durch einen 
Interpretierer ist; . 

Fig. 12 eine schematische Darstellung ist, die eine allgemeine Struktur eines Kompiberers gemaB einer Ausfuhrungs- 
form der vorliegenden Erfindung veranschauiicht; 

Fig. 13 eine schematische Darstellung ist, die ein Beispiel eines Blockwahlers gemaB einer Ausfuhrungsform der vor- 
liegenden Erfindung veranschauiicht; m . 

Fig. 14 ein Blockbild einer Codeubersicht mit zwei extemen Einsprungpunkten ist, wobei Fullzeichen zwischen der 
Einsprung- bzw. engl. ENTRY-Instruktion und der Sprung-nach- bzw engl. GOTO-Instruktion eingefugt wurden; 

Fig. 15 ein Blockbild ist, das ein OASSIGN-Einfugungsbeispiel veranschauhcht; 

Fig. 16 ein Blockbild ist, das ein Beispiel einer Totcodeeliminierung und Adressenprufungseliminierung veranschau- 
iicht 

Fig. 17 ein Blockbild eines Beispiels einer Adressenprufungseliminierung ist; 

Fig. 18 ein Blockbild eines Beispiels einer gemeinen Teilausdruckeliminierung bzw. engl. Common Subexpression 
Elimination ("CSE M ) ist; 

Fig. 19 ein Blockbild einer Kopierpropagation bzw. engl. Copy Propagation ist; 

Fig. 20 insbesondere ein Beispiel einer konstanlen Faltung bzw. engl. Constant Folding veranschauiicht; 

Fig. 21 insbesondere ein Beispiel des obigen Prozesses gemaB einer Ausfuhrungsform der vorliegenden Erfindung 
veranschauiicht, der eine Vergleichsinfrastruktur auf weist; 

Fig. 22 insbesondere ein Beispiel der Codegenerierung fur dieselbe Instruktion mit unterschiedlichen umgebenden In- 
struktionen veranschauiicht; _~.ji.i-u 

Fig. 23 eine Systemkonfiguration gemaB der zweiten Ausfuhrungsform der vorliegenden Erfindung veranschauiicht, 
die zur dynamischen opumierenden Objektcode-Ubersetzung verwendet wird; 

Fig. 24 eine Systemkonfiguration gemaB der dritten Ausfuhrungsform der vorliegenden Erfindung veranschauhcht, 
die zur gleichzeitigen dynamischen Ubersetzung verwendet wird; 

Fig. 25 eineDifferenz zwischen der Kombination eines Interpreuerers und Kompilierers, beispielsweise wahrend der 
Ausfuhrung als eine Aufgabe, und ihrer Trennung, beispielsweise in verschiedene Aufgaben, gemaB einer dritten Aus- 
fuhrungsform der vorliegenden Erfindung veranschauiicht; 

Fig. 26 eine UbersetzungstabeUe gemaB einer vierten Ausfuhrungsform der vorliegenden Erfindung veranschauiicht, 
die zur Aufzeichniing verwendet wird, welche Tnstruktionen iibersetzbar sind und welche nicht; 

Fig. 27 veranschauhcht, wie das Verfahren die Belastung der Profilierung auf den Emulator gemaB einer vierten Aus- 
fuhrungsform der vorliegenden Erfindung reduziert; 

Fig. 28 eine allgemeine Strukturdarstellung eines dynamischen Dbersetzungssystems mit getrenntem InterpreUerer 
und Kompilierer gemaB einer funften Ausfuhrungsform der vorhegenden Erfindung veranschauiicht; 

Fig. 29 Komponenten eines Software-Ruckkopplungsmechanismus gemSB einer funften Ausfuhrungsform der vorhe- 
genden Erfindung veranschauhcht; 

Fig. 30 veranschauhcht, wie gemaB einer sechsten Ausfuhrungsform der vorliegenden Erfindung eine Wartescnlange 
zum Halten von t'Jbersetzungsanforderungen verwendet wird, wahrend die t'Jbersetzungsaufgabe belegt ist; 
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Fig, 31 veranschauiichl^^die OOCT-Anforderungswarteschlange koslengiir^(Pgcmeinsam genutzte Speichcran- 
forderungen mil Systcmaufrufan forderungen gemaB einer sechsten Ausfuhrungsform der vorliegenden Erfindung kom- 
biniert; 

Fig. 32 zeigt, wie gemaB einer siebenlen Ausfuhrungsform der vorliegenden Erfindung ein dynamischer Ubersetzer 
s Seitenfehler verursaehen kann, die wahrend der nonnalen Ausfuhrung der Quelleninstmktionen nichr aufireten wurden; 
Fig. 33 den Algorilhmus zur Behebung von Seitenfehlern wahrend der Uber setzung und die Fortsetzung derUberset- 
zung gemaB einer siebenlen Ausfuhrungsform der vorliegenden Erfindung zeigl; 

Fig. 34 ein Muster eines Steuerflusses in einem dynamischen Uberselzungssystem niit einen) Verzweigungsprofilierer 
gemaB einer achten Ausfuhrungsform der vorliegenden Erfindung veranschaulicht; 
i i " Fig. 35 veranschaulichi, wie gemaB einer neunten Ausfuhrungsfomi der vorliegenden Erfindung der dynamische 
Oberselzer Verzweigungprofilinfonnalionen verwendet, urn die Ausfuhrungswahrscheinlichkeit eines Basisblocks zu 
bercchnen. 

DETAILLffiRTE BESCHREIBUNG DER BEVORZUGTEN AUSFUHRUNG SFORMEN 

i ^ . 

Nun wird detailliert auf die bevorzugten Ausfuhrungsformen der vorliegenden Erfindung bezuggenommen, wovon 
licispieie in den beigeschlossenen Zeichnungen veranschaulicht sind, wobei sich ahnliche Bezugszahlen durchgehend 
uiil" ahnliche Elemente beziehen. 

ERSTE AUSFUHRUNGSFORM DER VORLIEGENDEN ERFINDUNG 

i 

I. SYSTEMUBERBLICK 

Die vorliegende Erfindung bezieht sich allgemein auf einen optimierenden Objektcode-tJbersetzer, nachstehend 
"( KXT, der eine dynamische Kompilierung eines Mikroprozessor-Instruktionssatzes als Teil eines Computerarchitek- 
un-Hniulalionssystems durchfuhrl. Die Koinpiherung isL dynamisch, da es keinen einfachen ZugriJT auf den Applikali- 
onMnsiruktionssatz vor der Laufzcil gibt. Die Vcrwcndung cincs Kompilicrcrs als Tcil des Objcktcodc T t)bcrsctzuhgssy- 
sieins cniiogbcht es dem System, eine Analyse und Optimierungen durchzufuhren, welche die Leistung der Emulation 
•je-jcnubcr auf Schablonen basierenden Ubersetzungen und auf Schablonen basierenden Interpretationen zu verbessem. 

v > 1 )cr I lost prozessor f Lir die Emulation ist vorzugsweise ein im Handel erhaldicher Prozessor, wie der Intel Pentium Pro. 
Die Architektur des Pentium Pro-Instruktionssatzes erleichtert die Manipulation verschiedener DatengroBen, und er- 
Icichlcn dadurch die Emulation sowohl von 16 Bit- als auch 8 Bit-Objektcode-Instruktionen. Die 16 Bit- und 8 Bit-Ob- 
jcktcode-Instruktionen konnen fiir eine Origin alapplikati on auf einem zweiten Prozessor, wie einem Prozessor der K-Se- 
rie von Fujitsu, ausgebildet sein. 

Die Durchfuhrung sinnvoller Optimierungen vom Kompiherer-Typ ist nur duirch die Kenntnis eines InstruktionsfluB- 
graphen moglich. In einem tradidonellen Kompilierer ist der FluBgraph gegeben und gut definiert, da die gesamte Rou- 
itne einer vollstandigen Sprachanalyse unterzogen wird, bevor die Optimierung beginnt Bei einem OOCT ist dies nicht 
der Fall. Bevor das Programm lauft, ist der Ort der Instruktionen im Speicherbiid unbekannt. Dies ist darauf zuriickzu- 
miiren, daB die Insiruktionen eine variable Lange mit willkurlichen intervenierenden Satzen von Nicht-Instruktionsdaten 

-it) aulwciscn. Der Ort der Instruktionen ist unbekannt, ebenso wie der Ort aller Verbindungspunkte in die Instruktionen. 

Daher muB zur Bestimmung des RuBgraphen das Programm laufen gelassen werden. Zuerst laBt ein Interpreuerer das 
Progranmi laufen. Wahrend der Interpreuerer das Programm ausfuhrt, informiert der Interpreuerer den OOCf jedesmal, 
vvenn er eine Ver/.weigungsoperation durchfuhrt. Diese Protokollierung von InformaUonen idenufiziert einige der In- 
siruktionen und einige der Verbindungspunkte. Wahrend das Programm lauft, werden die Informationen uber den RuB- 

45 graphen zwar vollstandigen jedoch niemals ganz vollstandig. Das OOCT-System ist ausgebildet, mit Teilinformationen 
Tiber den FluBgraphcn zu arbeiien: die Opdmierung wird an potentiell unvollstandigen RuBgraphen durchgefiihru und 
das System ist ausgebildet, das Ersetzen des optimierten Codes mit zunehmender Verfugbarkeit von Informationen zu 
gestatten. 

Die dynamische Kompilierung wahlt auf der Basis der vom Interpreuerer gesammelten Profihnformationen,. welche 
50 Teile des Textes zu oplimieren sind. Wenn die Anzahl von Malen, die irgendeine Verzweigung ausgefuhrt wird, eine 
Schwellenanzahl uberschreitet, wird das Ziel dieser Verzweigung ein Startparameter fur die Kompiherung. Der Startpa- 
ramcter ist ein Startpunkl Hir eine Sprachanalyse eines Teils der K-Instruktionen, die als Einheit zu kompilieren sind. 
Dies wird Segment genannt. 

Ein Segment enthalt Hostprozessorinstruktionen, die aus der Optimierung der Originalprozessorinstrukdonen vom 
55 Startparameter resultieren. Ein Segment wird als Einheit installiert und deinstalliert. Wenn der Interpreuerer den OOCT 
aufruft, um uber eine Verzweigung zu intbrmieren. kann der OOCT wahlen, die Steuerung in das Segment zu transrerie- 
ren, wenn der Code fur das Ziel existiert. Ahnlich kann dz Segment einen Code zum Transferieren der Steuerung zuriick 
zum Interpreuerer enthallen. 

Ein Segment selbst kann un vollstandig sein, so daB das Segment nur einen Teilsatz der moglichen RuBpfade vom Ori- 
60 ginal programm reprasentiert. Diese unvollstandige Reprasentation beeinfluBt jedoch nicht den korrekten Betrieb der 
Emulation. Wenn ein neuen unvorhergesehener RuBpfad durch den Originalcode auftritt, springt der SteuerfluB zuriick 
zum Interpretierer. Spater kann dasselbe Segment ersetzt werden, um den neuen SteuerfluB zu beriicksichtigen. 



65 



H. OOCT-CODESTRUKTUR 

GemaB einer Ausfuhrungsform der vorliegenden Erfindung kann der OOCT unter einer herkomrnlichen Betriebssy- 
stemumgebung wie Windows laufen. GemaB einer zweiten Ausfuhrungsform der vorliegenden Erfindung kann der 
OOCT jedoch eingerichtet sein. mit einer Emulations-Firmware auf einem zweiten Betriebssystem verbunden zu wer- 
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den, wie dem KOI- Bel riebssysteiJBPF Fujitsu. 

in. ARCHITEKTUR 

Fig. 1 veranschaulichl die hohere Archilektur des OOCT- Systems 100. Fig. 1 veranschaulichl zwei Aufgaben, nani- 
lich einen Interpretierer 110 und einen Kompilierer 104. Der Inlerprelierer 110 und der Kompiiierer 104 operieren gleich- 
zeitig unler eineni Mehraufgaben-Betriebssystem. Die zwei Aufgaben konnen beide durch einen Verzweigungsprotokol- 
lierer 112 auf ein Verzweigungsprotokoll zugreifen, und konnen auch auf die kompilierten Codesegmente 108 zugreifen. 
AuBerdem kann der Interpretierer 110 Kompilierungsantbrderungen an den Kompilierer 104 senden. Eine vollstandigere 
Beschreibung der Kommunikaiion zwischen den beiden Aufgaben erfolgt im nachstehend angegebeneri Kommumkati- 
onsabschniti. 

KOMPTT JERUNGSFT .US SSTHUKRUNG 

Fig 2 veranschaulichl die Hauptkomponenten des OOCT 100 zusamnien mil dem SteuerfluB zur Kompilierung eines 
Abschnitts des Originalcodes. Die Haupi-OOCT-Stufen sind wie folgt. Zuerst profiliert der Interpretierer 110 Verzwei- 
gungsinformationen durch die Kommunikation mit dem VerzweigungsprotokoUierer 112. Der Verzweigungsprotokoiiie- 
rer 112 verwendet dann ein Startparameter- Auswahlverfahren, urn zu bestimmen, welche Startparameter an den Kompi- 
lierer 104 zu senden sind. AnschlieBend verwendet der Blockwahler 114 den Startparameter und die Verzweigungspro- 
filinformationen, urn ein Segment des zu kompilierenden Originalcodes zu wahlen. Dann schaflft der Blockwahler 114 ei- 
nen SteuerfluBgraphen (CFG), der die zu kompilierenden Originaiinstruktionen beschreibt, und reicht den CFG an die 
Blockaufbaueinheit 116 weiter. . ' 

AnschlieBend flacht die Blockaufbaueinheit 116 den SteuerfluBgraphen zu einer linearen Liste von Instruktionen ab. 
Die optimierende Codegenerierungseinheit 118 fuhrt die tatsachliche Kompilierung der Originaiinstruktionen in iiber- 
setzte Codesegmentinstruktionen durch. Der produzierte ubersetzte Code, zusammen mit Inforrnationen uber das Seg- 
ment, das kompiliert wird, wird schlieBlich zur SegiiientinstaUationseinheit 120 weilergereicht, die den Code fur den In- 
terpretierer 110 vcrfugbar macht. 

ock:t-ausfuhrungssteuerfluss 

Fig. 3 veranschaulicht den SteuerfluB im OOCT wahrend der normalen Ausfuhrung. Wahrend der Interpretierer 110 
den Code ausfuhrt, kann der OOCT in den VerzweigungsprotokoUierer 112 einspringen, wenn er bestimmte Instruktio- 
nen ausfuhrt. Der VerzweigungsprotokoUierer 112 kann entweder zum Interpretierer 110 zuruckspringen, oder, wenn das 
Ziel der Verzweigung bereits kompiliert wurde, in eines der instaUierten Segmente des kompilierten Codes einspringen. 
Vom kompitierren Code konnen Ubergange von Segment zu Segment oder zuriick zum Interpretierer 110 durchgefiihrt 
werden. Der kompilierte Code kann entweder den Interpretierer 110 aufrufen, um eine einzelne Originalinstruktion aus- 
zufuhren, oder kann zum Interpretierer 110 springen, wobei die gesamte Steuerung an den Interpretierer 110 weiterge- 
reichtwird. . . 

Eine Beschreibung der ersten Ausfuhrungsform der vorhegenden Anmeldung wird wie folgt unterteilt. Der erste Ab- 
schnitt beschreibt die Schnittstelle zwischen dem Interpretierer 110 und dem Kompiherer 104. Der zweite Abschmtt be- 
schreibt die Modifikationen, die am Interpretierer 110 fur den OOCT durchgefiihrt wurden. Der dritte Abschnitt be- 
schreibt den Kompilierer 104. Der abschliefiende Abschnitt beschreibt eine Windows-Testumgebung. 

Der Beschreibung der ersten Ausfuhrungsform folgt eine Beschreibung der zweiten bis neunten Ausfuhrungsform der 
vorhegenden Erfindung. 

IV. KOMMUNIKATION (GEMEINSAME EINHETT) 

Der Interpretierer 110 und der Kompiherer 104 kommunizieren miteinander auf verschiedenen Wegen. Der Interpre- 
tierer 110 zeichnet Verzweigungsinformationen in ein Verzweigungsprotokoll auf, indem er mit dem Verzweigungspro- 
tokoUierer 112 kommuniziert. Der Kompilierer 104 kann auch das VerzweigungsprotokoU lesen. Der Kompilierer 104 
schafft kompiUerte Codesegmente und speichert ihre Einsprungpunkte in der Ubersetzungstabelle, die der Interpretierer 
110 liest. Der Interpretierer 110 sendet auch Startparameteradressen an den Kompilierer 104 liber einen Puffer. Der Quel- 
lencode, der sowohl vom Kompiherer 104 als auch vom Interpretierer 110 fur diese Kommunikation verwendet wird, be- 
rindet sich im gemeinsamen Verzeichnis. Dieser Abschnitt beschreibt, wie die Kommunikation funktioniert. 

GHMHINSAM GENUrZ'llLR OOCT-PUFFER 

Die gesamte Kommunikation zwischen dem Kompiherer 104 und dem Interpretierer 110 wird durch den OOCT-Puf- 
ferbereich gefuhrt, der eine groBe Region des gemeinsam genutzten Speichers ist. Bestimmte Kommunikation verwendet 
auch Systemaufrufe, um Nachrichren vom Interpretierer 110 an den Kompilierer 104 und zuriick zu senden. 

Die nachstehende TabeUe 1 veranschaulicht eine Abbildung der statisch zugeordneten Teile des OOCT-PufFers. Der 
Rest des Puffers wird dynamisch fur verschiedene Datenstrukturen zugeordnet, die in der auch nachstehend angegebenen 
TabeUe 2 gezeigt werden. Einige Felder im statisch zugeordneten Teil des OOCT-Puffers zeigen auf Datenstrukturen im 
dynamisch zugeordneten Teil. Diese Zeiger haben hochgesteUte Nummern, um darzusteUen, wohin sie zeigen. Das Zo- 
nenfeld im statisch zugeordneten Teil hat beispielsweise die Nummer 2, und das Zonenfeld zeigt auf die Zonenspeicher- 
Datenstruktur im dynamisch zugeordneten Teil, die auch die Nummer 2 hat. 
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Tabelle 1 



Der statisch zugcordnclc Teil des OOC1 -Puffers 



5 


Feld 


Di- 
stanz 


Inhalt 


10 


jump_table 


Oh 


Ein Array von Einsprungpunkten im 






Interpretierer 110, wie IC_FETCH02 , 
IU_PGMxx. OOCT_INIT schreibt sie, 


15 






und der Kompilierer 104 liest sie, 
Der Kompilierer 104 verwendet sie, 
um Sprunge zum Interpretierer 110 zu 


20 






generieren. 




trans_master_ 


lOOOh 


Ein Array von Zeigern, einer fur 


25 


target^ 




jede Seite im ASP-Adressenraum. Fur 


table 1 




eine Seite, die der ASP nicht ver- 
wendet, ist der Zeiger 0. Fur eine 


30 






Seite, die der ASP verwendet, zeigt 
der Zeiger auf ein Array im 
dynamisch zugeordneten Teil des 


35 






OOCT-Puf fers (siehe unten) . 




unallocated 


41004h 


Ein Zeiger, der auf das erste un- 
genutzte Byte im dynamisch zugeord- 


40 




- 


neten Teil des Puffers zeigt. Wird 
nur wahrend der Initialisierung ver- 
wendet . 


45 


length_lef t 


4100811 


Die Anzahl von Bytes, die im dyna- 
misch zugeordneten Teil des Puffers 


50 






zuriickbleiben. Wird nur wahrend der 
Initialisierung verwendet. 




num exces 


4100Ch 


Nummer des Interpretierers 110. 



55 
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Feld 


Di- 
stanz 


Inhalt 


zones 2 


41010h 


Ein Zeiger auf den Zonenspeicher, 
der im dynamisch zugeorctefegfefili Teil 
des OOCT-Puffers ist. OOCT_INIT 
schreibt den Zeiger, wahrend der 
Kompilierer 104 den Zeiger liest. 
Der Kompilierer 104 verwendet den 
Zonenspeicher wahrend der Kompilie- 
rung. 


zones_length 


41014h 


Der Betrag des Zonenspeicher s . Wird . 
von OOCT_INIT geschrieben und vom 
Kompilierer 104 gelesen. 


segments 3 


41018h 


Ein Zeiger auf den Segment speicher , 
der im dynamisch zugeordneten Teil ! 
des OOCT-Puffers ist. 00CT_INIT 
schreibt den Zeiger, wahrend der 
Kompilierer 104 den Zeiger liest. 
Der Kompilierer 104 verwendet den 
Segmentspeicher, um den kompilierten 
Code zu speichern. 


segment s_ 
length 


4101Ch 


Der Betrag des Segmentspeichers . 
Wird von OOCT_rNIT geschrieben und 
vom Kompilierer 104 gelesen. 


tables 4 


41020h 


Ein Zeiger auf Verzweigungscache- 
strukturen erster Ordnung (LI) , die 
im dynamisch zugeordneten Teil des- 
OOCT-Puffers sind. 


branch_record_ 

free_ 

list 5 


41024h 


Eine Liste ungenutzter BRANCH__RECORD 
Strukturen, die im dynamisch zuge- 
ordneten Teil des OOCT-Puffers sind. 
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Feld 


Di- 
stanz 


Inhalt 


table 5 


41028h 


Eine Hash-Tabelle, die 
BRANCH_RECORD-Strukturen enthalt. 
Die Tabelle wird dynamisch im OOCT- 
Puffer zugeordnet . 


branch__log_ 
lock 


4102Ch 


Eine Verriegelung, die gehalten 
werden mufi , um das Verzweigungspro- 
tokoll zu schreiben. 


branches eed_ 
buffer 


4103 Oh 


Ein Puffer, den der Interpretierer 
110 verwendet, um Startparameter an 
den Kompilierer 104 zu senden. 


num_moni tor_ 
seed_ 

messages 


41060h 


Ein Zahler, der. mitteilt, wie viele 
Nachrichten der Interpretierer 110 
an den Kompilierer 104 gesendet hat, 
die der Kompilierer 104 jedoch nicht 
beendet hat. 


seed_ 

CUXe S HO X CJL 1UUQ.C 


41064h 


Eine Flagge, die dem Interpretierer 
110 mitteilt, wie ein Startparameter 
zu wahlen ist. Der Startparameter 
ist entweder OOCT_DEBUG_MODE oder 
OOCT_PERFORMANCE_MODE . 


seed. 

product ion_ 
threshold 


*± X w O 0 1^ 


Die Schwellenanzahl von Mai en , die 
eine Verzweigung ausfilhren mufi, 
bevor ihr Ziel ein Startparameter 
fur den Kompilierer 104 wird. 


trickle^ f lush_ 
ll_rate 


4106Ch 


Die Anzahl von Mai en, die eine Ver- 
zweigung in einem Ll-Cache aktuali- 
c-? prf werden kami. bevor die Ver— 
zweicmncr aus dem Cache creraumt wird 
und in den Speicher zuruckgeschrie- 
ben wird. 


seeds_sent 


41070h 


frei bzw. engl . UNUSED 


seeds handled 


41074h 


UNUSED 
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Feld 


Di- 
stanz 


Inhalt 


exit 


41078h 


Der Kompilierer 104 verwendet diese 
Flagge, urn den Interpretierer 110 
mitzuteilen, da£ der Kompilierer 104 
nach dem Empfang eines Signals den 
Betrieb eingestellt hat. 


segment_exit 


4107Ch 


Ein Einsprungpunkt im Interpretie- 
rer 110, zu dem der kompilierte Code 
beim Ausgang springt. Der Code an 
diesem Einsprungpunkt gibt Verrie- 
gelungen frei, wenn notwendig. 


s egment_exi t_ 
interp 


41080h 


Ein Einsprungpunkt im Interpretie- 
rer 110, zu dem der kompilierte Code 
beim Beenden einer Instruktion, die 
interpretiert werden mu£, springt. 
Der Code an diesem Einsprungpunkt 
gibt Verriegelungen frei, wenn 
notwendig. 


s egment_exi t_ 
log 


41084h 


Ein Einsprungpunkt im Interpretie- 
rer 110, zu dem der kompilierte Code 
beim Beenden einer nicht-f estgeleg- 
ten Verzweigungsinstruktion springt. 
Der Code an diesem Einsprungpunkt 
gibt Verriegelungen frei, wenn 
notwendig. 


sbe_impl 


41088h 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, urn die SBE-Instruktion aus- 
zufuhren.. 


cc_impl 


410 8Ch 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, urn die CC-Instruktion aus- 
zuf uhr en . 
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Feld 


Di- 
stanz 


Inhalt 


rr\\r *i mn 1 

III V_X1U^/J» 


41090h 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, urn die MV-Instruktion aus- 
zuf iihren . 


inv_impl_s ame_ 

S3 X £m c; 


41094h 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, um die MV-Instruktion aus- , 
zufuhren, wenn die Langen beider 
Zeichenf olgen gleich sind. 


s egment.l ock_ 
mousetrap 


41098h 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, um zu verif izieren, da£ er - 
weiterhin eine Verriegelung halt, 
DIES WIRD NUR ZUR DIAGNOSE 
VERWENDET . 


breakpoint^ 
trap 


410?Ch 


Ein Einsprungpunkt im Interpretie- 
rer 110, den der kompilierte Code 
aufruft, um das Diagnoseprogramm zu 
Stoppen. DIES WIRD NUR ZUR DIAGNOSE.. 
VERWENDET . 


cftcrmpnf <Tr3 •Hoc 

t«y ILL CXi. L. M Ci w ^> 


410A0h 


Ein Array von SEGMENT_GATE-Struktu- 
ren. Die SEGMENT_GATEs werden zur 
Verrieorelung von Segmenten des kom- 
pilierten Codes verwendet . 


ga t e_f r e e_l i s t 


710A0h 


Eine Liste aktuell ungenutzter 
SEGMENT GATES. 


ooct_s tack_ 
bottom" 7 


710A4h 


Die unterste Adresse des Stapels des 
Kompilierers 104. Zeigt in den dyna- 
misch zugeordneten Teil des OOCT- . 
Puffers • 
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Feld 


Di- 


Inhalt 






stant 




5 


ooct_stack_ 


710A821 


Die hochste Adresse des Stapels des 


top 7 




Kompilierers 104. Zeigt in den dyna- 








misch zugeordneten Teil des OOCT- 


10 






Puffers. 




build_options 


710ACh 


Die fur den Aufbau des Interpretie- 








rers 110 verwendeten Optionen. In 


15 






ooct_ compiler_start priift der Kom- 








pilierer 104, daS er mit denselben ; 


20 






Optionen aufgebaut wurde. 


code_zone 2 


710BOh 


Ein Zeiger auf einen Bereich des dy- 








namisch zugeordneten Speichers. Der 


25 






Kompilierer 104 verwendet diesen 








Speicher zur temporaren Schaf fung 








eines Arrays von Zielinstruktionen. 


30 






Am Ende der Kompilierung wird dieses. 








Array in den Segmentspeicherbereich 


35 






kopiert und dann geloscht. 



Im dynamisch zugeordneten Teil des OOCT-Puffers sind die GroBen von Datenstrukturen von verschiedenen Varia- 
blen abhangig. Eine ist die Anzahl von Systemseiten, die vom Betriebssystem fiir den Originalprozessor, wie den ASP 
von Fujitsu, verwendet werden. Fiir jede Seite eines ASP-Adressenraums, der zu ubersetzende Instruktionen enthalt, gibt 
es eine iibersetzte Seite in der Ubersetzungstabelle. Eine weitere Variable ist die Anzahl von Verzweigungsinstmktionen, 
die das System zu protokollieren erwartet. Aktuell erwartet es 2 20 Verzweigungen, was die GroBe des BRANCH_RE- 
CORD-Arrays und die Verzweigungs-Anfangsblocktabelle beeinfluBt. Die Anzahl der Interpretierer 110 beeinfluBt die 
GroBe des Ll-Verzweigungsprotokollierer-Cache, da es fur jede Aufgabe einen Cache gibt. 

Fig. 4 veranschaulicbt eine Abbildung des OOCT-Puffers fur eine Einstellung der Variablen. In Fig. 4 betragt die An- 
zahl von ASP-Sei ten 10 MB ASP-Instruktionen, die Anzahl der Interpretierer ist 4, und die GesamtgroBe des OOCT-Puf- 
fers betragt 128 MB. 
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Tabcllc 2 



Der dynamisch zugcordnclc Teil des OOCT-Puffers 



Name 


Inhalt 


Translation 
Table 1 


Fur jede Seite Adressenraum, der vom ASP 
genutzt wird, gibt es eine in der Uber- 
setzungstabelle zugeordnete 16 KB-Seite. 
SIZE = Anzahl von Sys terns ei ten * 16 KB. 


BRANCH_RECORD 
array 5 


Wir haben geschatzt, wie viele Verzwei- 
gungsinstruktionen im ASP auftreten (der- 
zeitige Schatzung 2 20 ) , und ein 
BRANCH_RECOKD wird fur jede zugeordnet. 
SIZE = 2 20 * 24 Bytes = 24 MB. 


Branch header 
table 6 


Es gibt einen Zeiger auf einen 
BRANCH_RECOKD fur jede geschatzte Verzwei- 
gung. SIZE = 2 20 * 4 Bytes = 4 MB. 


Branch Ll 
caches* 


Fiir jeden Interpretierer 110 gibt es einen 
Cache mit 32 Satzen, 4 BRANCH_Ll_RECORDs 
pro Satz. SIZE = Anzahl Ausfuhrungen * 
32 * 4 * 24 Bytes. Maximal e SIZE = 
16 * 32 * 4 * 24 Bytes = 49152 Bytes. 


OOCT stack 7 


Ein 1 MB-Stapel. 


Zone memory 2 


Ein Prozentsatz des verbleibenden Spei- 
chers wird fur den Zonenspeicher verwen- 
det. Aktuell werden 50 % Speicher ver- 
wendet . 


Segment memory 3 


Ein Prozentsatz des verbleibenden Spei- 
chers wird fur den Segmentspeicher verwen- 
det. Aktuell werden 50 % Speicher ver- 
wendet . 



VERZWEIGUNGSPROTOKOLL (VERZWEIGUNGSPROTOKOLXIERHR 112) 

Die VerzweigungsprotokoU-Datenstrukturen sind das BRANCH_RECORD- Array, die Verzweigungs-Anfangsblock- 
tabelle und die Verzweigungs-Ll -Caches. Fiir eine Hrlauterung, wie der Verzweigungsprotokollierer 112 arbeitet, siehe 
bitte Dachstehend angegebener Abschnitt uber Interpretierermodifikationen. Dieser Abschnitt beschreibt, wie das Ver- 
zweigungsprotokoll verwendet wird, um Inform ationen vom Interpretierer 110 zum Kompilierer 104 zu kommunizieren. 

Fig. 4 veranschaulicht den OOCT-Puffer nach der Initialisierung. Die GroBen der Regionen sind mafistabgetreu ge- 
zeichnet. Fur dieses BeispieJ betragt die GroBe des OOCT-PurYers 128 MB, die Anzahl von ASP-Seiten betragt 2560, die 
Anzahl von Interpretierem 110 betragt 2, und die erwartete Anzahl von Verzweigungsinstruktionen betragt 220. 

Der Kompilierer 104 liest das Verzweigungsprotokoll, um herauszufinden, wie viele Male eine bedingte Verzwei- 
gungsinstruktion eingeschlagen wurde, und wie viele Male eine bedingte Verzweigungsinstruktion nicht eingeschlagen 
wurde. Der Kompilierer 104 verwendet diese Informationen auf zwei Wegen. Erstens, wenn der Kompilierer 104 die In- 

12 



19945992A1 J_> 



DE 199 45 992 A 1 ^ 

slruklionen eincr Sprachanalysc^^P^iehl, vcrsucbl der Konipilierer 104 nur die InstruSKen der Sprachanalyse zu un- 
icrziehen, die am haufigslen ausgcfuhri wurden. Wenn cine bedingle Vcrzweigungsinsiruklion auftriu, priifi er, wie viele 
Male sic sich verzweigt hal, und wie viele Male sic fehlgeschlagen isi. Zweitens, wenn der Konipilierer 104 einen Code 
generiert, versucht der Konipilierer, die wahrscheinlichsle Nachrolgcrinsiruktion ciner bedingten Verzweigung unmittel- 
bar nach der Verzweigungsinstniklion zu plazieren. Dadurch la'uft der genericrte Code schneller. Uni niitzuteilen, wel- 
cher Nachtblger wahrscheinlicher ist, verwendei der Konipilierer 104 Verzweigungsprotokollinfbrmalioncn. Fur nahere 
Hinzelheilen siehe bitte nachstehende Inionnationen iiberden Konipilierer 104. 

B RANCH_Gel_Record (oocl/conipiler/branc h .c) 



TRANS JEntry_FlagP (ooct/common/trcommon .h) 

Das Makro TRANS_Entry_FlagP hest den Zustand einer der Flaggen JOIN, ENTRY oder BUFFERED des Uberset- 
zungslabelleneinlrags und fuhrl ihn zuruck. 

TRANS_Test_And_Set_Entry_Flag (ooct/common/ircommon .h) 

Die Prozedur TRANS_Test_And_Sel_Entry_Flag liest automatisch den Zustand einer der Flaggen JOIN, ENTRY 
oder BUFFERED und schaltet sie ein, wenn sie nicht bereits eingeschaltet war. Sie fiihrt den Zustand der Flagge zuruck, 
bevor sie die Prozedur aufruft. 



10 



Wenn der Konipilierer 104 Verzweigungsprolokollinfonnationen lesen will, ruft er die Prozedur BRANCII_Get_Re- 
cord mit der Adresse der Verzweigungsinslruktion auf. Diese Prozedur schlagl die Verzweigung im Verzweigungsproto- 
koll nach und fiihrt einen Zeiger auf eines der Hlemente des BR ANCH_R ECORD- Arrays zuruck. Dann kann der Koni- 
pilierer 104 sehen, wie viele Male die Verzweigungsinstruktion ausgefiihrt wurde, wie viele Male sie sich verzweigt hat, 
und wie viele Male sie fehlgeschlagen ist. 15 

UBERSETZUNGSTABELLE (UBERSETZUNGSEINHEIT) 

Die Ubersetzungstabelle enthalt Informationen iiber jede Instruktion im ASP-Adressenraum. Die Ubersetzungstabelle 
/cichnct auf, ob die Instruktion das Ziel einer Verzweigung ist (JOIN), ob die Instruktion zum Konipilierer 104 als Start- 20 
Parameter gesendet wurde (BUFFERED) und ob es einen kompilierten Einsprungpunkt fur das Segment gibt (ENTRY). 
Wenn der OOCT initialisiert wird, isi die Ubersetzungstabelle leer. Wenn die Verzweigungsinstruktionen protokolliert 
ucrden, werden ihre Ziele als JOIN-Punkte markiert. Wenn die Verzweigung mehrere Male als die Schwelle ausfiihrt, 
\\ ird das Ziel als Startparameter an den Kompilierer 104 gesendet, und der Ubersetzungstabelleneintrag wird als BUF- 
II-.KED markiert. Nachdem der Kompilierer 104 die Kompilierung der ubersetzten Version beendet, speichert er die 25 
Adrcsscn von Einsprungpunklen in der Ubersetzungstabelle und markiert sie als ENTRYs. 

Hg. 5a, 5b und 5c vcranschaulichcn die Struktur ciner Ubersetzungstabelle gcmaB eincr bevorzugten Ausfuhrungs- 
lonn der vorliegenden Erfindung. Wie in Fig. 5a veranschaulicht, wird eine ASP- Adresse in zwei Teile geteilt. Die obe- 
ren 20 Bits sind die Seitennuminer. und die unteren 12 Bits sind die Seitendistanz. 

M|5» 5b veranschaulichl, da6 die Seitennummer als Index in die Ubersetzungstabelle erster Ordnung verwendet wird. 30 
Die Seilen, die der ASP bearbeitel, sind in der Tabelle erster Ordnung. Die Seiten, die der ASP nicht verwendet, haben 
keme Zeiger, da es niemals eine Instruktion mit dieser Seitennummer geben wird. Die Zeiger zeigen in die Ubersetzungs- 
Libel 1c zweiter Ordnung. Das Hinzufugen einer Seitendistanz zum Zeiger ergibt einen Ubersetzungstabelleneintrag. 

Wie in Fig. 5c. veranschaulicht, ist jeder Eintrag 32 Bits lang, und seine Felder sind unten dargestellt. Das erste Bit be- 
sagi. ob die ASP-Instruktion ein Verbindungspunkt ist Das zweite besagt, ob es einen Segmenteinsprungpunkt fur die In- 35 
sirukiion gibl. Das dritte besagt, ob die Instruktion zum Kompilierer 104 als Startparameter gesendet wurde. Die anderen 
Biis des Obersetzungstabelleneintrags sind die Einsprungpunktadresse fur die Instruktion, wenn es eins gibt, oder 0 gibt, 
lulls kein Einsprungpunkl vorliegt. 

Da die K-Maschinenarchileklur Inslruktionen mit variabler Lange aufweist, hat die Ubersetzungstabelle einen Eintrag 
liir jede ASP- Adresse, einschlieBlich der Adressen, die in der Mitte der Instruktionen und Datenadressen iiegen. Dies 40 
much! die Tabelle schr groB, es yereinfacht jedoch das Vorhaben der Lokalisierung des Ubersetzungstabelleneintrags flir 
eine Adresse. Die Slruktur der Ubersetzungstabelle ist in Fig. 5a, 5b und 5c gezeigt. Wie oben angegeben, hat die Uber- 
sei/.ungslabclle zwciler Ordnung einen 32 Bit-Eintrag fur jede ASP- Adresse. Wenn daher der ASP 10 MB Raum verwen- 
dei, verwendei die Uberser/.ungsiabelle zweiter Ordnung 40 MB. Es gibt verschiedene Prozeduren und Makros, welche 
die Hintrage der Ubcrsclzungsiabelle lesen und schreiben. 45 

TRANS_S et _Entry_Flag (ooct/common/trcommon.h) 

Das Makro TRANS. Sei liniry_Rag schaltet eine der Flaggen JOIN, ENTRY oder BUFFERED des Ubersetzungsta- 
belleneinirags ein. Es verwendei eine Assembhersprachinstruktion mit dem Verriegelungsprafix, so daB es das Bit auto- 50 
maiiseh setzt. 

TRANS Reset Entry Flag (ooct/common/trcommon.h) 

Das Makro TRANS_Resct_Entry_Flag schaltet eine der Flaggen JOIN, ENTRY oder BUFFERED des Ubersetzungs- 55 
tabelleneintrags aus. Es verwendet eine Assembhersprachinstruktion mit dem Verriegelungsprarix, so daB es das Bit au- 
tomatisch zuriicksetzt. 
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TRANS_Sei_Entry_Address (ooct/common/trcoHR.h) 

Die Prozedur TRANS^Set_Entry_Address schreibt die Einsprungpunktadresse des Ubersetzungstabelleneintrags. Sie 
verwendet eine Assembliersprachinstruktion mit dem Verriegelungsprafix, so da6 sie die Adresse automatisch schreibt. 
5 Es ist zu beachten, daB eine Einsprungpunktadresse die Adresse einer Zielinstruktion isl. wenn keine Segmentverriege- 
lung besleht, jedoch die Adresse einer SEGMENT GATE-Datenstruktur ist, wenn eine Segment verriegelung besteht. 

TRANS_Get_Entry_Address (ooctycommon/urcommon.h) 

10 Die Prozedur TRANS_Get_Entry_ Address best die Einsprungpunktadresse des Ubersetzungstabelleneintrags und 
fuhrt diese zuriick. Es isl zu beachten, daB eine Einsprungpunktadresse die Adresse einer Zielinstruktion ist, wenn keine 
Segmentverriegelung besteht, jedoch die Adresse einer SEGMENT_GATE-Datenstruktur ist, wenn eine Segmentverrie- 
gelung besteht. 

15 SEGMENTE 

Ein Segment ist eine Einheit eines kompilierten Codes, der vom KOI-System ausgefuhrt werden kann. Nachstehend 
angegebenes Material uber den Kompilierer 104 beschreibt, wie der Kompilierer 104 den Interpretierer 110 uber ein Seg- 
ment informiert, wie der Interpretierer 110 in das Segment einspringt und dieses verlaBt, und wie der Kompilierer 104 

20 den Interpretierer 110 anweist, die Verwendung eines Segments zu stoppen und zu einem anderen zu wechseln. 

Wenn ein Segment geschaffen wird gibt es einige ASP-Instruktipnsadressen, wo der Interpretierer 110 in das Segment 
einspringen kann. Fur jede dieser Adressen schafrt der Kompilierer 104 einen Einsprungpunkt in das Segment. Ein Ein- 
sprungpunkt ist ein spezieller Punkt im Segment, wo der Interpretierer 110 hinspringen darf. An anderen Punkten im 
Segment nimmt der kompilierte Code an, daB bestimmte Werte in Registem vorliegen, so daB es nicht sicher ist, dorthin 

25 zu springen. Um dem Interpreuerer 110 mitzuteilen, wo die Einsprungpunkte sind, ruft der Kompilierer 104 
TRANS_Set_Entry_Address f iir jede n.le TRANS JjetJEn try .Address auf. 

Der Interpretierer 110 pruft auf kompilierte Codcscgmcntc, wenn sic in den Vcrzwcigungsprotokoilicrcr 112 einsprin- 
gen. Sie rufen TRANS_Entry_FlagP auf, um zu sehen, ob die aktuelle ASP-Adresse einen Einsprungpunkt aufweist. 
Wenn sie dies tut, rufen sie TRANS_Get_Entry_Address auf, um die Adresse zu lesen. Wenn die Segmentverriegelung 

30 ein ist, verriegeln sie das Segment (siehe unten) und springen dann zum Einsprungpunkt. Wenn die Segmentverriegelung 
aus ist, springen sie nur zum Einsprungpunkt. Der kompilierte Code entscheidet, wenn er aussteigen soil. Dies geschieht 
ublicherweise, wenn er eine Instruktion ausfuhren muB, die nicht Teil desselben Segments ist, so springt er zum Interpre- 
tierer 110. 

Der Kompilierer 104 kann ein kompiliertes Codesegment loschen und den Interpretierer 110 anweisen, ein anderes zu 
35 verwenden. Der Kompilierer 104 tut dies, indem er das ENTRY-Bit des Ubersetzungstabelleneintrags ausschaltet, die 
Einsprungpunktadresse andert und dann das ENTRY-Bit wieder einschaltet. 

SEGMENTVERRIEGELUNG 

40 Die Segmentverriegelung ist ein optionales Merkmal des OOCT-Systems. Da der VerzweigungsprotokoUierer 112 mit 
dem Laufen des Systems mehr Informationen sammelt, kann der Kompilierer 104 eine neue Version eines Segments pro- 
duzieren, die besser ist als die alte. Die Segmentverriegelung ermoglicht dem Kompilierer 104, ein altes Segment durch 
ein neues zu ersetzen und den vom alten Segment verwendeten Speicher emeut zu beanspruchen. Leider macht die Seg- 
mentverriegelung den VerzweigungsprotokoUierer 112 und den kompilierten Code langsamer. Daher kommt es zu einem 

45 Abtausch zwischen der Zeit zur Ausfuhrung des OOCT-Codes und dem Raum, den er verwendet. Dieser Abschnitt be- 
schreibt, wie die Segmentverriegelung arbeiteL 

Der Segmentverriegelungscode hat zwei Hauptteile. Der erste Teil ist eine Schnittstelle fur alle Teile des OOCT-Sy- 
stems mit Ausnahme der Segmentverriegelungsimplementation. 

Diese Schnittstelle garantiert, daB sich ein Segment nur in einem von vier gut derlnienen Zustanden befinden kann, 

50 und Zustande auf gut definierten Wegen automatisch andert Der zweite Teil ist die Implementation der Segmentverrie- 
gelung selbst, wodurch die von der Schnittstelle gegebenen Garantien erfullt werden. 

AUSBILDUNG (DESIGN) 

55 Die Zustande, in denen sich ein Segment befinden kann, werden in Tabelle 3 gezeigt. Ein Segment kann entweder er- 
reichbar oder unerreichbar sein, und es kann entweder verriegelt oder unverriegelt sein. Segmente sind erreichbar, wenn 
es einen oder mehrere Einsprungpunkte in die Ubersetzungstabelle gibt. Es ist unerreichbar, wenn es keine Einsprung- 
punkte in das Segment in der Ubersetzungstabelle gibt. Ein Einsprungpunkt ist eine Struktur, die eine Verriegelung und 
eine Instruktionsadresse enthalL Die Verriegelung, die gleichzeitig von mehr als einem Interpretierer 110 verwendet wer- 

60 den kann, zahlt, wie viele Tnterpretierer 110 den Einsprungpunkt und das diesen enthaltende Segment verwenden. Ein 
Segment ist verriegelt, wenn einer oder mehrere seiner Einsprungpunkte verriegelt sind. Es ist unverriegelt, wenn alle 
seiner Einsprungpunkte unverriegelt sind. 

Der Kompilierer 104 kann ein Segment emeut beanspruchen und loschen, wenn es unerreichbar und unverriegelt ist, 
er kann es jedoch nicht emeut beanspruchen, wenn es erreichbar oder verriegelt ist. Jedes Segment beginnt im Zustand 

65 UAJ, wenn es der Kompilierer 104 schaffL Es bewegt sich in einen Zustand RAJ, wenn der Kompilierer 104 seine Ein- 
sprungpunkte in die Ubersetzungstabelle schreibt. Es kann sich zu einem Zustand R/L und zuriick zu RAJ bewegen, wah- 
rend Interpreuerer 110 in das Segment einspringen und dieses verlassen. Der Kompilierer 104 kann ein neues Segment 
schaffen, das dieselben Instruktionen ubersetzt wie ein altes Segment In diesem Fall uberschreibt er die Einsprung- 
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punkle des alien Segments in de^^HkselzungstabeUe, wodurch es unerreichbar wird.^^^i der Kompilierer 104 den 
ieizien Einlrag des Segments ubcrsc Tircibt., gcht es vom Zustand R/L zu U/L, wenn es von einem Interpretierer 110 ver- 
wendet wird, oder vom Zustand R/U zu U/U, wenn cs von keinem InterpretiererllO verwendct wurde. SchlicBlich geben 
alle das Segment verwendenden Interpret ierer 110 ihre Verriegelungen frei, und das Segment befindet sich im Zustand 
U/U. Der Kompilierer 104 kann dann das Segment crncul beanspnichen und es loschen, da es von keinem Interpret ierer 
110 verwendet wird, und keiner in dieses springen kann. 



Tabelle 3 



Die Zustande, in denen sich ein Segment befinden kann 



Zustand 


Erreichbar 


Verriegelt 


Beschreibung 1 


U/U 


Nein 


Nein 


Kein Interpretierer 110 ver- 
wendet das Segment/ und kein 
Interpretierer 110 kann in 
dieses einspringen. Der Kompi- 
lierer 104 kann es jederzeit < 
loschen. 


R/U 


Ja 


Nein 


Kein Interpretierer 110 ver- 
wendet das Segment. 


R/L, 


Ja 


Ja 


Ein oder mehrere Interpretie- 
rer 110 verwenden das Segment ... 


U/L 


Nein 


Ja 


Ein oder mehrere Interpretie- 
rer 110 verwenden das Segment - . . 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



Fig. 6 veranschaulicht einen Interpretierer 110 zum Einspringen in ein Segment 122 und Verlassen desselben gemaB 
einer Ausfuhrungsform der vorliegenden Erfindung. Das Segment 122 in der Mitte der Zeichnung ist die Codeeinheit, 
die vom Kompilierer 104 produziert wird. Das Segment 122 muB zu jeder Zeit, wenn es vom Interpretierer 110 verwen- 
det wird, verriegelt sein. DemgemaB wird ein Verriegelungszahler (nicht gezeigt) inkrementiert, bevor in das Segment 
122 eingesprungen wird, und der Verriegelungszahler wird dekrementiert, nachdem das Segment 122 verlassen wurde. 
Da der Interpretierer 110 den Einsprungpunkt nicht nachschlagen und den Einsprungpunkt automatisch verriegeln kann, 
muB bestimmt werden, ob der Einsprungpunkt, nachdem er verriegelt wurde, nicht geandert wurde. 

Fig. 7 veranschaulicht ein Verfahren des Kompilierers 104, um ein Segment zu schaffen, das Segment durch den In- 
terpretierer 110 erreichbar zu machen, alte Segmente unerreichbar zu machen, und alte Segmente zu loschen. In Schritt 
S200 schafft der Kompilierer 104 ein neues Segment und fiigt assoziierte Einsprungpunkte zur Ubersetzungstabelle 
hinzu. Wenn ein Einsprungpunkt in Schritt S200 hinzugefugt wird, kann ein alterer Einsprungpunkt umgeschrieben wer- 
den. Der altere Einsprungpunkt ist nun unerreichbar, und kann demgemaB erneut verwendet werden, wenn keine Auf- 
gabe (wie der Interpretierer 110 oder Kompilierer 104) eine Verriegelung darauf halt. Der alte Einsprungpunkt wird auf 
eine Liste zum erneuten Beanspruchen (nicht gezeigt) gesetzt. 

Der Schritt 202 veranschaulicht, wie der Kompilierer 104 die Liste zum erneuten Beanspruchen verwenclet. Der 
Schritt 202 pruft, ob ein Einsprungpunkt verriegelt ist. Wenn der Einsprungpunkt nicht verriegelt ist, dann wird der Ein- 
sprungpunkt von keinem Interpretierer 110 verwendet, und kann daher aus dem Segment, zu dem er gehort, entfernt wer- 
den. Wenn das Segment jedoch keine weiteren Einsprungpunkte hat, dann wird das Segment nicht von einer Aufgabe 
(wie dem Interpretierer 110 und Kompilierer 104) verwendet, und keine Aufgabe kann in dieses springen. Daher kann 
das Segment geloscht werden. 

Die Segmentverriegelungsschnittstelle ermoglicht, daB mehrere Teile des OOCT die Details der Synchronisation 
ignorieren, da sich ein Segment immer in einem gut definierten Zustand zu befinden scheint, und alle Zustandsubergange 
automatisch zu erfolgen scheinen. Innerhalb des Segment verriegelungscodes erf olgen jedoch die Ubergange nicht auto- 
matisch, da das Tntel-Ziel einen derartig komplizierten Betrieb in der Hardware nicht unterstutzL Daher laBt. der Seg- 
mentverriegelungscode die Ubergange automatisch erscheinen. 



IMPLEMENTATION 



Die Prozeduren zum Ausflihren des Interpreuerers 110 und Kompilierers 104 sind in Fig. 6 bzw. Fig. 7 veranschau- 
licht. Die beiden Prozeduren arbeiten zusammen, um sicherzustellen, daB jeder Ubergang automatisch erscheint. Die 
Zahlenreferenzen in der folgenden Beschreibung beziehen sich auf 6 und Fig. 7. 

Es gibt sechs mogliche I Jbergange unter den vier Zustanden der Segmentschnittstelle, und sie fallen in vier Gruppen. 
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Der erste Ubergang isl U/t^HTR/U, wcnn der Konipilierer 104 ein Segment erreil^PF macht, indeni er seine Einsprung- 
punkte in die Ubersetzungstabelle schreibi (*6). Da der Konipilierer 104 die einzige Aufgabe ist, die in die Ubersel- 
zungstabelle schrciben darf, ist keine Synchronisation notwendig, urn diesen Ubergang automatisch zu rnachen. Die 
zweite Gruppe von Ubergangen ist R/U zu U/U und der ahnliche von R/L zu U/L. Diese geschehen, wenn der Kompilie- 
s rer 104 den letzlen Einsprungpunkt eines Segments in der Ubersetzungstabelle uberschreibt (*306). Obwohl der Kompi- 
lierer 104 einen neuen Einsprungpunkt automatisch in die Uberseizungsiabelle schrciben kann, kann der Interpret ierer 
110 einen Einsprungpunkt nicht automatisch lesen und verriegeln (*301, *302). Der Interpretierer 110 muB den Ein- 
sprungpunkt in einer Operation lesen und ihn in einer anderen Operation verriegeln. Dies fuhrt zu einem polentiellen 
Problem, daB, wenn ein Interpretierer 110 einen alten Einsprungpunkt aus der Ubersetzungstabelle liest, der Konipilierer 
in 104 dann einen neuen schreibt, und der Interpretierer 110 anschlieBend den alten Einsprungpunkt verriegelt. In diesem 
1 "all nimml der Konipilierer 104 an, daB der Einsprunggunkt unerreichbar ist, aber der Interpretierer 110 kann in das Seg- 
ment, einspringem was ein Fehler ist. Um dieses Problem zu verhindem, pruft der Interpretierer 110, da£ die Uberset- 
/.nngslabelle denselben Einsprungpunkt nach der Verriegelung enthalt (*303). Wenn die Ubersetzungstabelle denselben 
Einsprungpunkt enthalt, ist es weiierhin erreichbar, und es ist sicher, in das Segment einzuspringen. Wenn die Uberset- 
i % /.ungstabelle nicht denselben Einlrag enthalt, muB der Interpretierer 110 seine Verriegelung freigeben und darf nicht in 
ilas Segment einspringen. 

Die dritte Gruppe von Ubergangen ist RAJ zu R/L und umgekehrt von R/L zu R/U. Der erste geschieht, wenn ein In- 
terpretierer 110 den Einsprungpunkt aus der Ubersetzungstabelle liest und diesen verriegelt (*302). Der zweite geschieht, 
w enn der Interpretierer 110 ein Segment an seinem Ausgang verlaBt (*304) und zur Entriegeiungsprozedur geht (*305). 
» > Its ist wichlig, daB die Verriegelungs- und Entriegelungsinstruktionen nicht selbst im Segment sind, da jedesmal, wenn 
das Segment entriegelt wird, der Konipilierer 104 dieses ioschen kann (*3011). 

Der vierte Ubergang ist von U/L zu U/U. Er geschieht auch, wenn der Interpretierer 110 ein Segment verlaBt (*304) 
mi J /.ur Entriegeiungsprozedur geht (*305). Nachdem dieser Ubergang eintritt, wird das Segment entriegelt, und der 
Konipilierer 104 fuhrt die beiden Tests durch (*309, *3010) und loscht das Segment. 

Da der Interpretierer 110 die Verriegelung auf einem Segment fur einen willkurlichen Zeitraum halten kann, ist es in- 
L-rii/.icnl, den Konipilierer 104 auf eine Verriegelung warlen zu lassen. Daher versuchl der Konipilierer 104 nicht, Ein- 
sprting punkte zu verriegeln, um den Interpretierer 110 daran zu hindcrn, dicsc zu verwenden. Statt dessen macht cr das 
Segment nur unerreichbar und pruft spater, ob die Verriegelung freigegeben wurde (*309). Sobald die Verriegelung frei- 
jicjieben wird, kann der Einsprungpunkt frei gemacht und erneut verwendet werden. 

V) 

tJBERWA CHUNG SNACHRICHTENWARTESCHLANGEN 

Der Interpretierer 110 sender Startparameteradressen an den Kompilierer 104. Es werden zwei Nachrichtenwarte- 
schlangen verwendet, um sie zu senden. Die erste verwendet die KOI-Systemaufrufe ScMsgSnd und ScMsgRcv zum 

.« Senden und Ernpfangen von Startparametern. Die zweite Warteschlange verwendet einen gemeinsam genutzten Spei- 
chcrhereich im OOC'T- Puffer. Der gemeinsam genutzte Bereich wird branch_Seed_Buffer genannt. 

Der Grund fur die Verwendung von zwei Warteschlangen ist, daB jede einen Vorteil und einen Nachteil hat. Der KOI- 
Systcinaufruf ist fur den Interpretierer 110 kostspielig in der Verwendung, so daB er nicht sehr haufig verwendet werden 
sollte. Der AOI-Systemaufruf ennoglichl es jedoch dem Kompilierer 104 zu blockieren, wenn keine Startparameter zu 

4u koiupilieren sind. Dies ennoglicht, daB das KOI-System die CPU des Kompilierers 104 verwendet, um einige andere Ar- 
hciten zu erledigen. Der Vorteil des gemeinsam genutzten Speicherpuffers ist, daB er sehr kostengiinstig fur den Interpre- 
I ierer 110 ist, und der Nachieil ist, daB der Kompilierer 104 nicht blockieren kann, wenn es keine Startparameter gibt. 

Durch die Verwendung beider Warteschlangen nutzt der OOCT die Vorteile beider Verfahren. Wenn der Kompilierer 
104 Lintatig ist, rull er ScMsgRcv auf, um zu blockieren. In diesem Fall sendet der Interpretierer 110 den nachsten Start- 

-45 parameter mil einem ScMsgSnd- Aufruf, um den Kompilierer 104 aufzuwecken. Wenn der Kompilierer 104 arbeitet, sen- 
det der Interpretierer 110 Startparameter durch den branch_Seed_Buffer-Bereich, was schneller ist. Nachdem der Kom- 
pilierer 104 eine Kompilierung beendet, pruft er auf einen scb_Seed_BufYer-Bereich. Wenn es welche gibt, kompibert er 
sie. Wenn er alle Startparameter beendet, ruft er erneut ScMsgRcv auf und blockiert. 

so V L^iRPRETIERERMODIFEKATIONm (AUSFUHRUNGSEINHEIT) 

Die Ausbildung des OOCT enthalt drei Typen von Modiflkationen am Interpretierer 110. Erstens muB der OOCT vom 
Intcrpreuerer 110 inilialisiert werden. Zweitens wurde der Interpretierer 110 modifiziert, um eine Verzweigungsprotokol- 
lierung zu verwenden. SchlieBlich wurde der Interpretierer 110 modifiziert, um Ubergange zum und aus dem kompilier- 
55 ten Code zu ermdglichen. Dieses Dokument beschreibt die Details dieser Modifikatiohen. 

Der OOCr-Inierpretierercode kann in zwei Modi laufen, OOCT_PER>'ORMANCE_MODE und OOCT_DH- 
BUG_MODE. Diese Dokumentation beschreibt alle Merkmale des OOCT_PERFORMANCE_MODE und gibt an, wo 
sich der OOCTJDEBUG_MODE davon unterscheidet. 

60 TNTTT AT JSTERUNG 

Bevorder OOCT irgendeinen Code kompiliert oder irgendwelche Verzweigungen protokolliert, ruft der Interpretierer 
110 OOCTJNIT auf, um die OOCT-Datenstrukturen zu iniualisieren. OOCT.INIT und die Prozeduren, die dadurch 
aufgerufen werden, ftihren die folgenden Schritte durch. 
65 Die Ubersetzungstabelle iniualisieren. Die MCD-Instruktion informiert den OOCT uber die Seiten im Adressenraum 
des Systems. Die Prozedur TRANS_Execution_Init schafft die Ubersetzungstabelle erster Ordnung so, daB die Eintrage 
fiir Systemseiten auf Ubersetzungstabellen-Arrays zweiter Ordnung zeigen. Diese Arrays werden bei der Ininalisierung 
auf Null gesetzt. Fur genauere Details uber die t Jbersetzungstabelle siehe Kommunikationsabschnitt. 
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Vcrzweigungsprotokollicrer H^^Rtialisieren. Die Prozedur BRANCH_Execulion ilialisiert den Speicher im 

OOCT_bufier fur einige Datensirukiuren. Ersiens gibt es das Verzweigungsproiokoll selbsl, das Profilinformauonen 
iiber Verzweigungsinstruktionen enthall. Zweilens gibt es einen Cache erster Ordnung (LI), der den Verzweigungspro- 
tokoliierer 112 schneller opericren laBt. Driltens gibl es einen Slartparanieterpulfer, der vom Verzweigungsprolokollierer 
112 zum Kompilierer 104 gesendete St art parameter enthalt. Viertens gibt es einige globale Funktionen, die der kompi- 5 
lierte Code aufrufl. Ihrc Adressen werden im OOCT buffer wahrcnd BRANCH Execution Init gespeicherl. Fiir nahere 
Infonnationen iiber das Verzweigungsprotokoll und den Cache ersier Ordnung siehe obiger Abschnitt iiber den Verzwei- 
gungsprotokollierer 112. 

Stapeispeicher des Kompilierers 104 zuordnen. Der Kompilierer 104 verwendet einen speziellen groISen Stapel, der ini 
OOCT_buffer zugeordnet wird. 10 

1 . Zonenspcicher des Kompilierers 104 zuordnen. Der Kompilierer 104 verwendet diesen Speicher im OOCT_buf- 
fer wahrend der Kompilierung. 

2. Den kompi lierten Segment speicher zuordnen. Der kompilierte Code wird in diesem Bereich des OOCT_buffer 
plaziert. is 

3. Statistische Informationen auf Null setzen. Die meisten Informationen im OOCT-Statistikbereich werden zu- 
riickgesetzt, wenn der OOCT initialisierl wird. 

VERZWEIGUNGSPROTOKOLLEERER 

SCHNI1TSTELLE ZUM INTERPRETffiRER 

. Wenn der Interpretierer 110 eine Verzweigungsinslruktion im Systemcode ausfiihrt, und das OOCT-Modusbit geseizt 
ist, ruft der Interpretierer 110 den Verzweigungsprotokollierer 112 durch eine der folgenden Routinen auf: 
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_declspec (naked) OOCT_Log_Unconditional_Fixed_Branch( ) 
Abgerufen vom Interpret ierer mit einer Verzweignng 



Argumente : 


ausf . : Adresse der Verzweigungsinstruktion 


Rucksprunge : 


Springt nicht zunick (verhalt sich wie ein 
Sprung zu IC_FETCH02) 







_declspec (naked) O0CT_Log_Unconditional_Non_Fixed_Branch ( ) 


Abgemfen vom Interpretierer mit einer Verzweigung 


Argrumente: 


ausf.: Adresse der Verzweigungsinstruktion 




Springt nicht zuriick (verhalt sich wie ein 
Sprung zu IC_FETCH02) [ 







_declspec (naked) OOCT_Log_Condi tional_Fixed_Branch_Taken ( ) 
Abgerufen vom Interpretierer mit einer Verzweigung 



Argumente: 


ausf.: Adresse der Verzweigungsinstruktion 


Rucksprunge : 


Springt nicht zuriick (verhalt sich wie ein 
Sprung zu IC_FETCH02) 







_declspec (naked) OOCT_Log_Conditional_Fixed_Branch_Not_ 
Taken ( ) 


Abgerufen vom Interpretierer mit einer Verzweigung 


Argumente : 


ausf.: Adresse der Verzweigungsinstruktion 


Rucksprunge : 


Springt nicht zuriick (verhalt sich wie ein 
Sprung zu IC_FETCH02) 







Diese vier Routinen priifen auf einen kompilierten Einsprungpunki fUr die Zieladresse und springen zum Einsprung- 
punkt, wenn er exisuert. Wenn er nicht exisuert, darin aktualisieren die Routinen das Verzweigungsprotokoll durch das 
Aufrufen von branch_Ll_Touch (siehe nachster Abschnitt), und springen dann zur Abholroutine des Interpretierers 110. 

AKTUAUSEERUNG VON VERZWEIGUNGSPROTOKOIXTABELJJEN 

Fig. 8 veranschaulicht eine Struktur eines BRANCH_RECORD gemaB einer bevorzugten Ausfuhrungsform der vor- 
iiegenden Erfindung. 

Der Verzweigungsprotokolliercode zahlt, wie viele Male eine Verzweigung ausgefuhrt hat. Es gibi zwei Datenstruk- 
turen, die der Verzweigungsprotokoilierer 112 zum Speichern der Zahlungen verwendet. Erstens gibt es das Verzwei- 
gungsprotokoll. das von alien simulierten Prozessoren in einem Mehrprozessorsystem gemeinsam genutzt wird. Zwei- 
tens gibt es einen Cache erster Ordnung (LI) fur jeden simulierten Prozessorim System. Die Verzweigungsausfuhrungs- 

18 



19945992A1I > 



DE 199 45 992 A 1 

n^^Bc geschrieben und dann in das Verzweigungspr^^Bl 

de^Pf-Caches und des Verzweieunesproiokolls. Er bescnreib 



zahlungcn werden zuerst in den^^Be geschrieben und dann in das Verzweigungspr^^Wl geschrieben. Dieser Ab- 
schnitl beschreibi die Siruktur de^Pf-Caches und des Verzweigungsprotokolls. Er bescnreibt auch, wie der Verzwei- 
gungsprolokollierer 112 diese verwendet. 

Die Infonnationen fur jede Verzweigung werden in einer Struktur gespeichert. die BRANCH_RECORD genanni 
wird. Sie enlhall die Adresse der Verzweigung, das Ziel der Verzweigung, die Fehlschlag-Instruktion nach der Verzwei- 5. 
gung, die ungefahre Anzahl von Malen, welchc die \erzweigung ausgcfuhrl hal, und die ungefahre Anzahl von Malen, 
welche die Verzweigung eingeschlagen wurde. Das letzle Feld des BRANC3H_RECORD ist ein Zeiger auf einen anderen 
BRANCH_RECORD. Er wird verwendet, urn den BRANCH_RECORD in einer verketlelen oder verkniipften Lisle zu 
verbinden. 

Die Hash-Tabelle ist als Array verketteter Listen organisierl. 10 
Fig. 9 veranschaulicht die Struklur des Verzweigungsprotokolls. Es ist eine groBe Ilash-Tabelle, die BRANCII_RE- 
CORDs speichert. Jeder Interpretierer 110 hat seine eigene Kopie der variablen local_branch_header_table, sie zeigen je- 
doch alle auf dasselbe Array im OOCT-PufTerhereich. Die Elemente der 1ocal_branch_header_table sind Zeiger auf Li- 
sten von BRANCH_RECORDs. Die Prozedur zum Finden eines BRANCH_RECORD fur eine Verzweigung weist 3 
Schritte auf. 15 

1 . Hash-Codieren der Zieladresse. (index = BRANCH_HASH(desunalion_adaress) % BRANCH_TABLE_SIZE.) 

2. Kopf der Liste bzw. engl. head of list ermitteln. (list = local_branch_header_table[index].) 

3. Liste ab warts durcbgehen, bis ein Datensatz mit derselben Verzweigungsadresse gefunden wird. (while (lisl- 
>branch_address! = branch_address) list = iist->next.) 20 

Fig. 9 veranschaulicht insbesondere, daB die variable local_branch_header_table ein Array von Zeigem auf Listen ist. 
Jede Liste enthalt BRANCH_RECORDs, die dieselbe Zieladresse aufweisen. Wenn es keine Liste gibt, ist der Zeiger in 
der local_branch_header_table NULL. 

Das Verzweigungsprotokoll enthalt alle Informalionen uber Verzweigungen, es weist jedoch auch zwei Probleme auf. 25 
Erslens sind das Nachschlagen und Einfiigen von BRANCH_RECORDS langsame Operationen. Sie sind zu langsam 
durchzufiihrcn, jcdcsmal wcnn der Interpretierer 110 cine Verzweigung protokollicrt. Zwcitcns vcrwcndcl jeder Interpre- 
tierer 110 dasselbe Verzweigungsprotokoll. Urn die Listen der BRANCH_RECORDs konsistent zu halten, kann nur eine 
Ausfiihrung zu einer Zeit auf das Verzweigungsprotokoll zugreifen. Dies verlangsamt das Mehrprozessorsystem noch 
mehr als das Einprozessorsystern. Urn diese Probleme zu beheben, gibt es einen LI -Cache fur jeden Interpretierer 110. 30 
Auf den LI -Cache kann rasch zugegriffen werden, und die Interpretierer 110 konnen auf ihre LI -Caches parallel zugrei- 
fen. Jeder Ll-Cache ist ein zweidimensionales Array von BRANCH_Ll_RECORD-Strukturen. Die Basisadresse des 
Arrays wird in der variablen branchJLl stable gespeichert. 

Fig. 10 veranschaulicht die Struktur des Ll-Cache. Der Cache ist ein zweidimensionales Array von 
BRANCH_Ll_RECORDs. Die erste Dimension ist BRANCH_L 1_SETS (aktueU 32), und die zweite Dimension ist 35 
BRANCH_L1_SETSIZE (aktueU 4). Jede Reihe des Arrays ist ein Satz. Dieselbe Verzweigungsinstruktion verwendet 
immer denselben Satz des Cache, er kann jedoch an verschiedenen Platzen sein. 

Wie in Fig. 10 veranschaulicht, ist der Ll-Cache in Satzen organisiert. Die Satznummer fiir eine Verzweigung ist 
gleich (branch_address +branch_destination) % BRANCH_L1_SETS. Die 4 Mitglieder des Satzes halten die 4 rieuesten 
Verzweigungen mit derselben Satznummer. Dies wird 4-weg-Satzassoziativitat genannt. Sie verbessert die Leistung des 40 
Cache, wenn einige Verzweigungen nahezu zur gleichen Zeit ausgefiihrt werden, die dieselbe Satznummer aufweisen. 

Fig. 11 veranschaulicht ein Verfahren zur Ausfiihrung des Betriebs des Ll-Cache durch den Interpretierer 110 gemaB 
einer Ausfuhrungsform der vorliegenden Erflndung. Mit anderen Worten veranschaulicht Fig. 11 ein Verzweigungspro- 
tokollierverfahren unter Verwendung des Ll-Cache. 

Das optimierende Objektcode-Ubersetzungs verfahren verwendet zwei Speicherformen zum Aufzeichnen nicht-kom- 45 
pilierter Verzweigungen, namlich 

1. ein Verzweigungsprotokoll mit einer sich dynamisch andernden GroBe proportional zur Anzahl aufgezeichneter 
Verzweigungen, und 

2. einen Verzweigungs-Cache, der als Ll-Cache bezeichnet wird, in dem eine begrenzte Anzahl nicht-kompilierter 50 
aufgezeichneter Verzweigungen in einer Reihenfolge gespeichert werden, die den ZugrifT erweitert. 

Das Verzweigungsprotokoll und der Ll-Cache reprasentieren virtuelle Speicherstellen, die von einem Betriebssystem 
verwaltet werden. Daher wird die Bezeichnung "Ll-Cache" willkurlich dem Cache zum Speichem nicht-kompilierter 
Verzweigungen verliehen und sollte nicht mit dem 'Ll-Cache' verwechselt werden, der allgemein auf einem Prozessor 55 
wie dem Pentium Pro zu finden isL 

Der optimierende Objektcode-Ubersetzer gemaB der vorliegenden Erfindung sieht vor, daB der Interpretierer 110 eine 
Vielzahl verse hiedener Verzweigungsprotokollierroutinen aufrufen kann. Jede Verzweigungsprotokollierroutine selbst 
ruft jedoch eine Subroutine auf, die entscheidet, zum kompilierten Code zu springen, oder eine Verzweigungsinstruktion 
zu protokollieren. Diese Subroutine wird insbesondere in Fig. 1 1 veranschaulicht. 60 

Angesichts des Obigen wird, um das Verzweigungsprotokollierverfahren mit dem Ll-Cache auszufuhren, zuerst das 
Verfahren in Schritt S400 gestartet. In Schritt S401 priift der Interpretierer 110 zuerst auf einen kompiberten Codeein- 
sprungpunkt fur das Verzweigungsziel (d. h. ob das betreffende Segment, vorher kompitiert wurde). Wenn ein Einsprung- 
punkt vorliegt, d. h. "Ja M , gibt es ein kompiliertes Segment, und der FluB springt zu Schritt S402 zur unmitteibaren Aus- 
fiihrung des kompilierten Codesegments. Die AusfUhrung des kompilierten Codesegments geht dann weitei; bis eine 65 
Endflagge erreicht wird, und der FluB springt anschlieBend fiir die Ausfuhrung des nachsten Segments zuriick. Selbstver- 
standlich wird die Verzweigung im Verzweigungsprotokoll nicht aufgezeichnet, daB die Verzweigung bereits kompiliert 
wurde. 
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Wenn in Schritt S401 M^insprungpunkl vorlicgl, d. h. "Nein", dann gibt es^Bffen kompilierten Code, welcher der 
Verzweigungsinslruktion enLsprichl. Der FluB gehr dann zu Schritl S404 weiier, und der Interpreiierer 110 sichi ini Ll- 
Cachc nach, um zu besliminen, ob eine moglichc Ubercinstininiung zwischen der \ferzweigung und der Vielzahl von 
Verzweigungen besleht, die im Ll-Cache gespeichen sind. 
5 Schritl S404 beslimmt, ob eine Obereinsliinnuing zwischen der Vcrzweigung und der Vielzahl von Verzweigungen be- 
steht, die im Ll-Cache gespeichen sind. Der LI -Cache isl in eine Vielzahl von Satzen geicill, wobei jeder Salz mit einer 
eindeutigen Satznummer bezeichnet isl. GemaB einer Ausfuhrungsform der vorliegenden Erfindung enthalt jeder Satz 
vier Verzweigungen. 

Schritt S404 bestinimt zuerst eine Cache-Satznumnier "S", die der aktuellen Verzweigungsadresse enlspricht, wobei S 

10 = (branch_address + branch_deslination) % BRANCH_L1_SETS. Als nachstes wird jedes Element der branch_Ll_ta- 
ble[S] sequentiell gegen die aktuelle Verzweigungsadresse und das Ziel geprufL Wenn eine Ubereinstimmung detekLiert 
wird, d. h. "Ja", dann gehl der FluB zu Schritt S406 weiter, und die Felder "encountered_sub_count" (ein Feld, das angibt, 
wie viele Male die Verzweigung gefunden wurde) und ,, taken_sub_counr (ein Feld, das angibt, wie viele Male die Ver- 
zweigung eingeschlagen wurde) werden aktualisiert. AnschlieBend geht der FluB zu Schritt S407 weiter. 

15 In Schritt S407 wird bestinimt, ob die aktuelle Verzweigungsadresse groBer als eine vorherbestimmte Schwellenan- 
zahl gefunden wurde. Der bevorzugte Schweilenwerl liegt in der GroBenordnung von 1000 Bits. So wird das Feld en- 
countered_sub_count mit dem Schwellenwert in Schritt. S407 verglichen. Wenn der Schwellenwert uberschritlen wird, 
d. h. "Ja", dann geht der FluB zu Schritt S410 weiter, und die im Cache gespeicherten Informationen fur diese Verzwei- 
gung werden in das Verzweigungsprotokoll zuruckgeschrieben. Wenn der Schwellenwert hingegen nicht uberschritten 

20 wird, d. h. "Nein", dann geht der FluB zu Schritt S412 weiter. Schritt. S412 ist ein Ende der aktuellen Subroutine, die zu 
IC-FETCH02 springt, d. h. dem Einsprungpunkt des Interpretierers 110. 

Wenn sich die korrekte Verzweigung nicht im Cache befindet, d. h. "Nein" in Schritt S404, dann geht der FluB zu 
Schritt S408 weiter, und ein BRANCHJL 1 ^RECORD (d. h. der Datensatz, der alle Felder, die aktualisiert werden kon- 
nen, enthalt, wie encountered_sub_count und taken_sub_count) im oben mit "S" bezeichneten Satz wird aus dem Ll-Ca- 

25 che entfernt und in das Verzweigungsprotokoll geschrieben. Als nachstes werden die aktuellen Verzweigungsinformatio- 
nen in den mil "S" bezeichnelen Satz geschrieben. Au6erdem wird wahrend des Schreibens des akluellen Verzweigungs- 
datensatzes in den Satz "S" der aktuelle Vcrzwcigungsdatcnsatz als crstcs Element des Satzcs plazicrt. Dies ist darauf zu- 
ruckzufuhren, daB dieselbe Verzweigung wahrscheinlich erneut ausgefuhrt wird, wodurch die Leistung und Emzienz des 
Systems zunehmen. Mit anderen Worten werden die Satze S404 rascher ausgefuhrt. Auch wenn sich die Verzweigung im 

30 Cache befindet, d. h. "Ja", kann sie in das Verzweigungsprotokoll kopiert werden, wenn sie eine groBe Anzahl von Malen 
ausgefuhrt hat, seit sie das letzte Mai geraumt wurde. 

Wenn der Ll-Cache verwendet wird, ist die Schrittsequenz fast immer S400, S404, S406, S407 und S412. DemgemaB 
versucht die vorliegende Erfindung, diese Schritte so schnell wie moglich zu machen. Wenn die aktuellen Verzweigungs- 
informationen in das erste Element des Satzes gesetzt werden, machen die \ferzweigungsinformationen den Schritt S404 

35 schneller, da der Interprederer 110 dieselbe Verzweigung wahrscheinlich erneut ausfuhrt. 

Das oben angegebene Verzweigungsprotokollierverfahren reduziert die Belastung fiir den Prozessor durch das Aus- 
fuhren eines Codes, der vorher kompiliert wurde, und das Erweitern eines Zugangs zu oft aufgerufenen Verzweigungs- 
instruktionen, welche die Schwellenhohe zur Kompilierung noch nicht erreicht haben. In dieser Hinsicht ist der Haupt- 
zweck des OOCT, den Schritt S400 dazu zu bringen, die "Ja" Verzweigung nahezu jedesmal einzuschlagen. Wenn eine 

40 Verzweigung" haufig ausgefuhrt wird, dann sollte ein kompiliertes Codesegment fur ihr Ziel vorliegen. 

Ein zweiter Zweck ist, den "Nein"-Pfad, der Schritt S401 folgt, schneUer zu machen, so daB Verzweigungen, die noch 
nicht kompiliert wurden, die Programmausfuhrung nicht merkbar verlangsamen. Der langsamste Teil des "Nein"-Pfads 
wird als "Raumung" bezeichnet. In beiden Schritten S408 und S410 werden \ferzweigungsinformationen aus dem Ll- 
Cache "geraumt" und in das Verzweigungsprotokoll geschrieben. Es wird notwendig, die Informationen einer Verzwei- 

45 gung zu raumen, um einen Startparameter an den Kompilierer zu senden; der veranlafit, daB ein kompilierter Code gene- 
riert wird, und den Schritt S400 veranlaBt, fur diese Verzweigung in der Zukunft "Ja" zu antworten. 

Es ist jedoch nicht notwendig, die Informationen der Verzweigung jedesmal zu raumen, wenn eine nicht-kompilierte 
Verzweigungsadresse ausgefuhrt wird. Eine Raumung alle 100 Ausfuhrungen oder weniger ist oft OK. Daher versucht 
die vorliegende Erfindung, die Geschwindigkeit der Schritte S400, S404, S406, S407 und S412 zu steigem, die keine 

50 Raumungen enthalten. So wird immer der schnellere Pfad eingeschlagen, auBer es passiert eines von zwei Dingen. In 
Schritt S404 ist es moglich, daB die Verzweigungsinformationen im Satz nicht gefunden werden, daher wird der "Nein"- 
Pfad zu S408 eingeschlagen. Wenn die Verzweigung ofter als die "Schwellen" anzahl von Malen ausgefuhrt wurde, wird 
in Schritt S407 der "Ja"-Pfad zu S410 eingeschlagen, der auch eine Raumung enthalt 

Im OOCT_DEBUG_MODE wird das Ll-Cacheverfahren weiterhin verwendet, die Schwelle zur Raumung des Cache 

55 wird jedoch auf 1 gesetzt, so daB die Inf ormauonen bei jeder Verzweigungsausfuhrung in das Verzweigungsprotokoll ge- 
schrieben werden. Dies macht den OOCT_DEBUG_MODE viel langsamer. 

STARTPARAMKTERAUSWAIIL (engl. = SEED SELECTION) 

60 Wenn eine Verzweigungsinstruktion sehr haufig ausgefuhrt wird, sendet der Verzweigungsprotokoll ierer 112 seine 
Zieladresse an den Kompilierer 104. Diese Adresse wird "Startparameter" genannt, und das Auswahlen von Startpara- 
metem ist ein sehr wichuger Teil des OOCT-Systems. 

Startparameter solllen Adressen sein, die am Beginn einer Prozedur oder am Kopf einer Schleife stehen. Daher sendet 
der Verzweigungsprotokollierer 112 nur Startparameter, die das Ziel einer unbedingten Verzweigung sind. Startparame- 

65 ter sollten Adressen sein, die haufig ausgefuhrt werden, so daB ein Verzweigungsziel nur ein Startparameter wird, wenn 
sein Feld encountered_count groBer als eine Schwelle ist. Die Schwelle wird im OOCT-Puffer im mit seed_producti- 
on_threshold bezeichneten Feld gespeichert. Die Schwelle kann sich mit der Zeit andern, was im nachsten Abschnitt be- 
schrieben wird. 
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Sliri^^ER SCITWELLE (engl. = THRESHOLD SETT^f 

Es gibt zwei nachieiligc Dinge hei der Vcrwendung einer festgeleglen Schwelle. uni zu entscheiden, ob cin St an para- 
meter gesendet wird. Ersiens kann die Schwelle zu hoch ein, wahrend der Kompilierer 104 untatig ist. In diesem Fall gib! 
es fiir den Kompilierer 104 niitzliche Arbeiien zu verrichien, aber der Verzweigungsprotokollierer 112 sagt dem Konipi- 5 
lierer 104 nicht, was zu lun isl. Zweitens kann die Schwelle zu niedrig sein, wahrend die Nachrichtenwarteschlange voll 
ist. In diesem Fall versucht der Verzweigungsprotokollierer 112 einen Start parameter zu senden, obwohl der Startpara- 
meter nicht in die Warteschlange pafil, was Zeitverschwendung ist. 

Gliicklicherweise ist es moglich, die beiden Situation zu detektieren, wenn der Kompilierer 104 untatig ist, urid wenn 
die Nachrichtenwarteschlange voll ist, und die Schwelle zu andem. Der Verzweigungsprotokollierer 112 deiekuert in der to 
Prozedur branch_Update_Entry durch das Lesen des als num_monitor_seed_niessages bezeichneten OOCT-Pufferfel- 
des, daB der Kompilierer 104 untatig ist. Wenn dieses Feld 0 ist, hat der Kompilierer 1 04 alle Starlparameter, die gesendet 
wurden, beendei. Die Schwelle ist zu hoch, daher senkt sie der Verzweigungsprotokollierer 112. Der Verzweigungspro- 
tokollierer 112 detektiert eine voile Nachrichtenwarteschlange in der Prozedur branch_Send_Seed, wenn er einen Start- 
parameter zu senden versucht, und bekommt einen Fehlercode, der anzeigt, daB die Nachricht nicht gesendet wurde. Die 15 
Schwelle ist zu niedrig, daher erhoht sie der Verzweigungsprotokollierer 112. 

Im OOCT_DEBUG_MODE andert sich die Schwelle nie. Ihr Wert wird in diesem Fall auf das dritte Argument der 
OOCT_INIT-Prozedur geseizt. 

MEHRAUFGABEN-BEHANDLUNG (engl. = HANDLING MULTITASKING) 20 

Der OOCT lauft auf einem Mehrprozessorsystem mit mehrfachen Interpretierem 110. Diese Aufgaben haberi indivi- 
duelle Verzweigungs-Ll -Caches, sie verwenden jedoch dieselbe Verzweigungsprotokolltabelle. Wenn Verzweigungsin- 
formationen aus dem LI -Cache in die Verzweigungsprotokolltabelle geraumt werden, belegt der Interpretierer 110 ein 
Protokoll auf der Tabelle, so daB es zu keinem Konflikt mit irgendeiner anderen Ausfuhrung kommt. Es gibt zwei mog- 25 
liche Wege, einen Slreii uni die Verzweigungsprolokollverriegelung zu behandeln. Der erste isl, einen Interpretierer 110 
wartcn zu lasscn, bis die Vcrricgclung vcrfugbar ist, und dann die Vcrricgclung zu crhaltcn und ihrc Vcrzwcigungsinfor- 
mationen zu schreiben. Dies laBt den Interpretierer 110 langsamer laufen, macht jedoch das Verzweigungsprotbkoll ge- 
nauer. Der zweite ist aufzugeben, ohne die Verzweigungsinformationen zu schreiben, wenn der Interpretierer 110 die 
Verriegelung nichl erhalten kann. Dieser Weg macht den Interpretierer 110 schneller, verliert jedoch einige Verzwei- 30 
gungsprotokollierinformationen. Der OOCT verwendet den zweiten Weg, da die Geschwindigkeil des Interpretierers 110 
wich tiger ist als die Genauigkeit des Verzweigungsprotokolls. Die VerzweigungsprotokoUinformationen mussen nur un- 
gefahr korrekt sein, damit das System gut funktioniert. 

Wenn der OOCT mit mehrfachen Interpretierem 110 lauft, ist eine der Aufgaben die spezielle Masteraufgabe, die 
OOCTJNTT aufruft, um den OOCT-Puffer und die Verzwei gungsprotokollier-Datenstrukturen zu initialisieren. Die an- 35 
deren Aufgaben sind Slaveaufgaben, die nur einige lokale Variablen und ihre Verzweigungs-Ll-Caches initialisieren 
mussen. Die Slaveaufgaben rufen SlaveOOCTJnit auf, nachdem die Masteraufgabe die Initialisierung des OOCT_-buf- 
fer beendet hat. Die Synchronisation zwischen Master- und Slaveaufgaben verwendet die folgenden Verfahren. , 

Masterverfahren 40 

1. MCD-Instruktion ausfiiliren, um OOCT einzuschalten. 

2. OOCT_INiT aufrufen, wodurch der OOCT-Puffer und Verzweigungsprotokollier-Datenstrukturen initialisiert 
werden. 

3. Slaveaufgaben aufwecken. 45 

4. Zurn Interpretierer springen. 

Slave verfahren 

1. Gehe zu Schlafmodus. Aufwachen, wenn Masteraufgabe ausfuhrt (Schritt 3 oben). 50 

2. SlaveOOCT_Inti aufrufen, wodurch der individuelle Verzweigungs-Ll -Cache der Aufgabe initialisiert wird. 

3. Zum Interpretierer springen. 



BENUTZER/SYSTEMRAUMUBERGANGE 
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Das OOCT-System kompiliert nur Instruktionen von den Systemseiten des ASP-Adressenraums. Es ignoriert die Be- 
nutzerseiten. Das OOCTSTS-Bit des individuellen Bereichs des Interpretierers 110 steuert, ob der Verzweigungsproto- 
kollierer 112 aufgerufen wird oder nicht. Dieses Bit wird hauptsachlich von den beiden Makros NEXT_CO und 
NEXT_OUN gesteuert. Es gibt jedoch einen Fall, wo der OOCT-Code dieses Bit setzen mu8. Wenn ein kompiliertes Co- 
desegment mit einer nicht-festgelegten Verzweigungsinstruktion endet, kann es PSW_TA veranlassen, sich vom System- 60 
raum zum Benutzerraum zu bewegen, was erfordert, daB OOCTSTS auf 0 gesetzt wird. Daher springt ein kompiliertes 
Codesegment, das mit einer nicht-festgelegten Verzweigung endet, zur Routine branch_Exit_Log, welche die Ziel- 
adresse pruft und das OOCTSTS-Bit korrekt setzt. 

65 
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KOMPELEERTII CX3DESCHNITTSTELI3I 
tXBERGANC} ZUM/VOM KOMPELDERTEN CODE 

5 Der Interpreiierer 110 transfericrl die Ausfiihrung zuni kompilienen Code, wenn der Interpret ierer 110 eine Verzwei- 
gungsprotokollierrouline aufruft, und er ein kompiliertes Codesegment fur das Verzwcigungszicl findet (siehe Fig. 11). 
Wenn die Segmentverriegelung ausgeschaltet ist, springt der Interpretierer 110 direkt zum Einsprungpunkt. Wenn die 
Segmentverriegelung eingeschaltet ist, muB der In terprei ierer 110 versuchen, das Segment zu verriegeln, bevor er zum 
Einsprungpunkt springt. Wenn er das Segment verriegell, dann springt er zum Einsprungpunkt. Wenn er das Segment 

to nicht verriegeln kann, springt er zuriick zum Inierpreuercr 110. 

Es gibt einige Wege zur Ausfiihrung, urn ein kompiliertes Codesegment zu verlassen, die in Tabelle 4 beschrieben 
werden. Wenn die Steuerung zum Interpretierer 110 zuruckspringt, haben in alien Fallen die ESI- und EDI-Register kor- 
rekte Werte, und der individuelle Bereich des Interpret ierers 110 hat perfekten K-Status. 
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Tabelle 4 

Wie die Steuerung ein kompiliertes Codesegment verlaBt 



End-K-OP-Code 


Was der kompilierte Code tut 


Festgelegte 
Verzweigung 
oder 

geradliniger 
K-OP-Code 


Testet, ob die Zieladresse einen kompi- 
lierten Einsprungpunkt hat. Wenn sie einen 
hat, dann wird ein Inters egmentsprung zum 
Einsprungpunkt durchgef uhrt . Wenn sie 
keinen hat, dann wird die Steuerung zum 
Interpretierer 110 bei IC_FETCH02 oder zu 
branch_Exit, wenn die Segmentverriegelung 
ein ist, zuruckgef uhrt . 


Nicht- 

festgelegte 

Verzweigung 


Springt zu branch_Exit_Log, wodurch das 
00CTSTS~Bit gesetzt und dann der Verzwei- 
gungsprotokollierer 112 aufgerufen wird, 
wenn PSW IA noch in einer Systemseite ist. 


LPSW, SSM, 
STNSM, MCD, 
CALL, KRTN, 
SVC, MC, BPC, 
LINK, LINKD, 
LOAD/ LOADD, 
DELT, DELTD, 
FBFCC 


Ohne Segmentverriegelung: springt zu 
IC_FETCH02, um den OP-Code auszufuhren. 

Mit Segmentverriegelung: springt zu 
branch_Exit- Interpret . 


SAM OP-Code, 
der zum RISC- 
Modus schaltet 


Ohne Segmentverriegelung: springt zu 
IC_FETCH02, um den SAM OP-Code auszu- 
fuhren. 

Mit Segmentverriegelung: springt zu 
branch Exit-Interpret. 



Wenn die Segmentverriegelung ein ist, halt der Interpretierer 110 eine Verriegelung auf dem kompilierten (?odeseg- 



BNSDOCID: <DE__1 9945992A1 J_> 



DE 199 45 992 A 1 



nienl. wahrend er diesen Code a^^^ri. Rr niuB diese Verriegelung freigeben, nachde^^^as Segment vcrlaBl, so ciaB 
der kompilierte Code einige Prozeduren im Vcrzweigungsproiokollierer 112 autruft, welche die Verriegelung freigeben, 
unit dann zum Interpret icrcr 110 springen. 

UNTERBRECHUNGEN 5 

lis gibt einige Unt.erbrechungen ? die eintreten konnen, wahrend der kompilierte Code ausfuhrt, wic IO-Unterbrechun- 
gen cxier MCHK-Unterbrechungen. Der kompilierte Code prufi das INTINF-Feld des individuellen Bereichs, um zu de- 
icklicren, ob eine Unterbrechung eingctretcn ist. Er pruti dieses Feld innerhalb irgendeiner moglichen unendlichen 
Schlcife, die sicherstelk, daB er die Unterbrechung nicht fiir immer ignorien. Wenn eine Unterbrechung eintriiL, rufi der to 
kompilierte Code die Interpretierer 110-Routine TU_OINTCIIK mil perfektem K-Status auf. Er erwartel, daB der Inter- 
pret ierer 110 zum konipilierten Code zuriickspringt. 



I>TrERPRETIERERRUCKRUFE 



VI. KOMPHJERER 
UBERJBLICK 
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liinige K-OP-Codes werden vom OOCT nicht ubersetzt. 

Stall dessen ruft der kompilierte Code die Interprelierer 11 0-S ubroutine IC_OOCT auf, um den OP-Code zu interpre- 
tieren und zum kompilierten Code zuriickzuspringen. Der kompilierte Code stellt sicher, daB die ESI- und EDI-Register 
die korrekten Werte aufweisen, und daB der individuelle Bereich perfekten K-Status hat, bevor IC_OOCT aufgerufen 
wird. 20 

Wcnn der Interpretierer 110 wahrend der Ausfuhrung der IC_OOCT-S ubroutine einen Fehler detekuert, ruft er die Pro- 
/.etiur ()OCT_EXCP auf, und springt nicht zum kompilierten Code zurtick. Wenn die Segment verriegelung eingeschaltet 
ist. gibt OOCT_EXCP die Segmentverriegelung frei. 

AUSNAHMEN 25 

Wenn cin iibcrsctzlcr OP-Codc cine urmaskicrtc Ausnahmc, wic cine Opcrationsausnahmc odcr cine Nulltcilcraus- 
nahme, aufweist, ruft der kompilierte Code eine In terpretierer-S ubroutine IC_PGMxx auf, wobei xx die Fehiercodenum- 
mer /.wischen Olh und 21h ist. Der Interpretierer 110 versucht, die Ausnahme zu behandeln und zuriickzuspringen. Wenn 
der Interpretierer 110 nicht zuruckspringen kann, ruft er OOCT_EXCP auf, wodurch jede Segmentverriegelung freige- 30 
geben wird. 

VERWENDUNG GLOBALER FUNKTIONEN 

liinige K-OP-Codes, wie Zeichenverarbeitungsoperationen, werden in eine groBe Anzahl von Ziel-OP-Codes uber- 35 
sci/j. Die Herstellung mehrfacher Ubersetzungen dieser OP-Codes wiirde zu viele der Segmentspeicher-Resubroutinen 
verw einlen. die globale Funktionen genannt werden, und die der kompilierte Code aufruft, um diese OP-Codes auszu- 
I uhrcn. Diese globalen Funktionen sind genauso wie Interpretierer 110-Routinen, die K-OP-Codes ausfuhren, auBer daB 
sie s|vziell geschrieben sind, um vom kompilierten Code aufgerufen zu werden, und zum kompilierten Code zuriickzu- 
springen. lis gibt globale Funktionen fur fiinf OP-Codes, SBE, CC, MV, TS und C Versuche zeigen, daB die globalen 40 
Funktionen viel schneller sind als der Aufruf des IC_OOCT-Einsprungpunkts des Interpretierers 110, und sie verwenden 
vie! weniger Speicher als das mehrfache Kompilieren des OP-Codes in Zielinstruktionen. 
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Bevor auf die Details der Kompilierung eingegangen wird, ist es wichtig, auf hoher Ebene den Hauptzweck des Kom- 
pilierers 104 zu verstehen, und die Struktur des Kompiberers 104 zu verstehen. Der Zweck des Kompilierers 104 ist die 
Uherseizung haufig ausgefuhrter Teile des aktuellen Ausfuhrungsprogramms in einen optirnierten Zielcode, und diesen 50 
Codc'lur den Interpreuerer 110 zur Ausfuhrung verfugbar zu machen. 

Kig. 1 2 veranschaulicht insbesondere eine allgemeine Struktur eines Kompilierers 104. Der Kompilierer 104 empfangt 
Slarlparameter vom Verzweigungsprotokollierer 112 (oben diskutiert), die den KompiUerungsprozeB starten. Der Start- 
parameter ist die Adresse einer Originalinstruktion, die das Ziel einer groBen Anzahl von Verzweigungen im aktuellen 
Ausfuhrungsprogramm gewesen ist. Dies soli einen Startpunkt bilden, um einen haufig ausgefuhrten Teil des aktuellen 55 
Ausfuhrungsprogramms zu hnden. Der Blockwahler 114 verwendet diesen Startparameter zusammen mit anderen Intbr- 
mationen, die vom Verzweigungsprotokollierer 112 vorgesehen werden, um Abschnitte des Programms zu wahlen, die 
kompiliert werden sollten. 

Sobald der zu kompilierende Originalcode gewahlt wurde, wird er drei Hauptstufen unterworfen. Die erste Stufe ist 
die TConvertierung der K-OP-Codes in eine Zwischensprache (TT rf ), die vom Rest des Kompilierers 104 verwendet. wird. 60 
Die Zwischensprache wird vom IL-Generator 124 generiert. Die zweite Stufe fuhrt verschiedene Analysen und optimie- 
rende Transformationen an der EL mittels der oben angegebenen Optimierung durch, die fur Referenzzwecke als Opti- 
mierer 126 bezeichnet wird. Die Endstufe konvertiert die IL in einen relativierbaren Maschinencode und wird als opti- 
mierende Codegenerierungseinheit 118 bezeichnet 

Der End- Job des Kompilierers 104 ist, den optirnierten Code fiir den Interpretierer 110 verfugbar zu machen. Dann 65 
wird eine Segmentdatenstruktur mit einer Kopie des optirnierten Codes durch eine Segmentinstallationseinheit geschaf- 
fen. AnschlieBend wird das Segment in einen gemeinsam genutzten Bereich innerhalb des OOCT-Puffers (nicht darge- 
stellt) installiert. Die t Jbersetzungstabelle wird schlieBlich aktuahsiert, so daB alle Verzweigungen vom Interpretierer 110 

23 



BNSDOCID: <DE_19945992A1_I_> 



DE 199 45 992 A 1 

zum kompiiierten K-Cod^Hnt dessen den neuen Ziclcode verwenden. 

Der Rest dieses Abschniits diskulieri deiailliert jede der obi gen KonipiIierer-104-Siufen. Am Ende dcs Abschnills 
werden auch einige andere verschiedcne Implement ationseinzelhcilcn erorierl. 

5 BLOCKWAHL (engl. = BLOCK PICKING) 

Der Konipilierer 104 empfangl eine einzelne Slarlparanieieradresse, uni die Kompiliemng zu siarten. Beginnend beim 
Startpararneter liest er Originalinstruktionen, bis er etwas wie einen Prozedurrumpf geiesen hat. Dann reicht er diesen 
S-atz von Originalinstruktionen zur nachsien Konipilierer- 104-Stufc ? der IL-Uenerierung, weiter. Die Instruklionseinhei- 
10 len, die der Konipilierer 104 liest, werden Basisblocke genannt, so daB diese Siufc als Biockwahler, d. h. Biockwahler 
114, bezeichnet wird. 

Ein Basisblock ist eine Sequenz von Instruktionen, wo die Sleucrung nur bei der ersten Instruktion einspringen kann, 
und nur bei der letzten Tnstruktion ausspringen kann. Das bedeulei, daB nur die erste Tnstruktion das Ziel einer Verzwei- 
gung sein kann, und nur die letzte Instruktion eine Verzweigungsinstruktion sein kann. Es bedeutet auch, daB, wenn die 
15 erste Instruktion des Blocks ausgefuhrt wird, dann alle Instruklionen ausgefuhrt werden. 

B LOCK W AHLER 

Fig. 13 veranschaulicht ein Beispiel des Blockwahlers 114 gemaS einer Ausfuhrungsform der vorliegenden Erfindung; 
20 Die Prozedur OOCT_ParseFrom implementiert den Biockwahler 114. Er best einen Basisblock zu einer Zeit. Ein Basis- 
block endet aus eineni von funf Griinden. 

1. Wenn der Sprachanalysierer eine Verzweigungsinstruktion best, endet der Block rnit der Verzweigung. 

2. Wenn die nachste Instruktion bereits einer Sprachanalyse unterzogen wurde, dann endet der Block mit der aktu- 
25 ellen Instruktion, da jeder K-OP-Code nur einmal in einem Segmenl auftreten sollte. 

3. Wenn die nachste Instruktion ein Verbindungspunki ist, dann endel der Block iuil der akluellen Instruktion, da 
sich Vcrbindungspunktc am Bcginn cincs Basisblocks bcfindcn musscn. 

4. .Wenn die aktuelle Instruktion ein Faktor ist, und darauf Daten anstelle von Instruktionen gefolgen konnten; dann 
endet der Block mit der aktuellen Instruktion. 

30 5. Wenn die aktuelle Instrukuon eine illegale Instruktion ist, dann endet der Block mit der aktuellen Instruktion. 

Nach dem Lesen jedes Blocks entscheidet der Biockwahler 114 in Abhangigkeit von der Weise, wie der Block geendet 
hat, welche Aktion als nachstes zu unternehmen ist. Die moglichen Aktionen sind in Tabelle 5 veranschaulicht. 
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Tabelle 5 

Aktion nach dem Lesen eines Blocks 


40 


Ende des aktuellen 
Blocks 


Aktion des Blockwahlers 114 


45 


Bedingte Verzwei- 
gung 


Sprachanalyse an der Fehlschlag-In- 
struktion und der Verzweigungszielin- 
struktion fortsetzen. 


50 


Unbedingte festge- 
legte Verzweigung 


Sprachanalyse an der Verzweigungsziel- 
instruktion fortsetzen . 




Nicht-festgelegte 
Ve r z we i gung 


Sprachanalyse stoppen, da Verzwei- 
gungsziel unbekannt ist . 


55 
60 


Faktor der Endin- 
struktion oder 
illegale Instruk- 
tion 


Sprachanalyse stoppen, da das nachste 
Byte keine Instruktion sein konnte. 


65 


Andere Instruk- 
tionen 


Sprachanalyse an der Fehlschlag-In- 
struktion fortsetzen. 



Ein Beispiel wird in Fig. 13 veranschaulicht. Der Biockwahler 114 beginnt an der Startpararneterinstruktion, die eine 
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LB-Instruktion ist. Da dies kein^^^weigungs- Oder Endfaktorinslrukiion ist. gehl er^^^chsieu Instruktion weiter. 
Diese ist eine TH-Instruklion, die erne bedingte Verzweigung isr. Der Blockwahler 114 stoppt das Lesen des Blocks we- 
gen der bedingten Verzweigung. Er setzt das Lesen neuer Blocke sowohl an der LH- als aach der LF-Instruktion fort. 
Wenn er die SVC- Instruktion liesU beendet der Blockwahler 114 diesen Block, da SVC eine Endfaktorinstruktion isl. 
Wenn er die GO Instruktion liest, beendet der Blockwahler 114 diesen Block, da GO eine Verzweigungsinstruktion ist . Er 5 
selzt das Lesen an der L8-Instruktion fort, da sie ein Verzweigungsziel ist. Nachdeni er die ST8-Instruktion liest, beendet 
der Blockwahler 114 den Block, da er bereits die nachsle Instruktion gelesen hat. 

Es gibt eine Obergrenze fur die Anzahl von Instmktionen, die der Blockwahler 114 liest. Der Zweck dieser Grenze ist 
zu verhindem, daB dem Koinpilierer 104 wahrend der Kompilierung der Quelleninstrukuonen der Speicher ausgeht. Die 
Grenze wird von der Konstante MAX_KINST_NUM in OOCT_trace.c gesetzt, und sie betragt derzeit 500. 10 

Der Blockwahler 114 kann einen Seitenfehler verursachen, wenn er versucht, eine Instruktion zu lesen. Wenn er einen 
Seitenfehler erhalt, stoppt der Blockwahler 114 das Lesen des aktuellen Blocks, setzt jedoch das Lesen ab irgendeinem 
Verzweigungsziel fort, das er noch nicht versucht hat. Dies errnoglichl dem Kompilierer 104, ein Segment, zu schaffen, 
auch wenn er nicht alle Instruktionen, die von einem Startparameter erreicht werden konnen, einer Sprachanalyse unter- 
ziehen kann. * 5 



BLOCKAUFBAU (BLOCK LAYOUT) 



Nach der Auswahl der Basisblocke ruft der Blockwahler die Prozedur OOCT_GenerateEL auf, urn die EL-Instruktio- 
nen zu generieren, die der Rest des Kompilierers 104 verwenden wird. Zu dieser Zeit ist es moglich, die Reihenfolge der 20 
Blocke umzuordnen. Dies wird Blockaufbau genannt, und es hilft dem Kompilierer 104, einen besseren Code fur den 
Pentium Pro-Prozessor zu produzieren, da der Pentium Pro schneller lauft, wenn bedingte \brwartsverzweigungen nicht 
eingeschlagen werden. 

Das Beispiel in Fig. 13 wird herangezogen. Es hat eine bedingte Verzweigung, die TH-Instruktion. In den Originalin- 
struktionen ist der Fehlschlag-Basisblock derjenige, der mit LH beginnt, und der Zielblock ist derjenige, der nut LF be- 25 
ginnt. Wenn die bedingte Verzweigung 75% der Zeit eingeschlagen wird, dann liiufl er schneller, wenn der LF-Basis- 
block in die Fchlschlag-Position und der LH-Basisblock in die cingcschlagcnc Vcrzwcigungsposition gcbracht wird. 

Die OOCT_GeneratelL-Prozedur baut die Blocke gemaB den Informationen im Verzweigungsprotokoll auf. Sie bring t 
die ublichsten Nachfblger bedingter Verzweigungen in die Fehlschlag-Position, wann immer sie kann. Diese Prozedur 
produziert eine Liste von EL-Instruktionen, die zu den Optimierungsphasen des Kompilierers 104 weitergereicht werden. 30 

GENERIERUNG DER ZWISCHENSPRACHE (IL) 

Der Abschnitt diskutiert den ProzeB der Generierung der Kompilierer-104-Zwischensprach(IL)-Reprasentation fur die 
K-Codes. Vor der direkten Erorterung, wie die IL generiert wird, wird ein Uberblick uber die IL gegeben, und Daten- 35 
strukturen, die wichtig zu verstehen sind, werden beschrieben. 

IL-UBERBUCK 

Die Hauptanalyse- und Transformationsdurchlaufe des Kompilierers 104 operieren in einer Zwischensprache, die ein 40 
spezieller maschinenunabhangiger Instruktionssatz ist. Die Verwendung einer Zwischensprache ist aus zwei Hauptgrun- 
den eine Standard-Kompilierer-104-Technik. Erstens hat eine IL typischerweise eine Architektur, die eine Analyse und 
Transformauonen vereinfacht. Zweitens ermoglicht eine IL vielen verschiedenen Quellensprachen, dieselben Optimie- 
rungs- und Codegenerierungsstufen zu verwenden, und erleichtert die erneute Zielrichtung auf verschiedene Plattfor- 
men. 45 

Die vom OOCT verwendete IL (ab hier nur als IL bezeichnet) ist derzeit aus 40 verschiedenen OP-Codes zusarnmen- 
gesetzt, die in Tabelle 6 aufgelistet sind. Die Instruktionen fallen in drei Hauptkategorien. Erstens gibt es funktionelle 
OP-Codes, wie ADD und LOAD, die ein geradliniges Mapping auf Standard-Maschinen-OP-Codes aufweisen. Zweitens 
gibt es OP-Codes, die den SteuerfluB behandeln, wie LABEL und CGOTO. SchlieBlich gibt es eine Anzahl spezieller 
OP-Codes, welche als spezielle Marker vom Kompilierer 104 verwendet werden, die nicht direkt dem Code entsprechen, 50 
der vom hinteren Ende generiert wird. Diese speziellen Marker-OP-Codes werden in einem getrennten Abschnitt be- 
schrieben. Da die IL eine virtuelle Maschine reprasentiert, ist es geradlinig, andere OP-Codes zur EL hinzuzufugen, wenn 
eine weitere Funktionalitat erforderlich ist. 

Die IL besteht aus Instruktionen, von denen jede einen der OP-Codes, einen Typ und eine Anzahl von Pseudoregister- 
argumenten spezifiziert. Die vom Kompilierer 104 unterstutzten iyP en sind 8 Bit-, 1 6 Bit- und 32-Bitwerte mit und ohne 55 
Vorzeichen. Abgesehen von Zwischenwerten, die vom SET-OP-Code verwendet werden, und Werten, die mit dem 
LOAD-OP-Code aus dem Speicher geladen werden, werden alle Argumente mit Pseudoregistem weitergereicht. Pseu- 
doregister sind einfach die Register der virtuellen IL-Maschine. Der Kompilierer 104 gestattet eine willkurliche Anzahl 
von Pseudoregistem, von denen jedes eine vordefinierte GroBe (z. B. 16 Bits) hat. Jedes Pseudoregister entspricht direkt 
einer spezifizierten Speicherstelle. Fur den OOCT sind diese Speicherstellen in den OOCT-spezifischen Teilen des indi- 60 
viduellen Bereichs. Dieses Mapping von Pseudoregistem in Speicherstellen hat zwei Vorteile. Erstens wird die IL ratio- 
nalisiert. Die IL-Operationen, urn allgemein verwendete Werte in temporare Speicher zu laden, und sie in den Speicher 
zuruckzuladen, sind nicht erforderlich. Zweitens kann der Kompilierer 104 oft allgemein verwendete Werte Maschinen- 
registern zuordnen, wodurch redundantes Laden oder Speichem ehminiert wird. 
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5 OP-CODE 

LABEL 

GOTO 

('GOTO 

'<> KJOTO 
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Tabelle 6 
IL-OP-Codes 



BESCHREIBUNG 

Markiert einen Platz im FluBgraphen, der das Ziel von Sprungoperationen sein konnte 
Ein Sprung zu einer Sprungniarke bzw. engl. label 

Ein bedingter Sprung zu einer Sprungmarke auf der Basis des Booleschen Werts eines 
Pseudoregisters 

Ein indirekter Sprung zu einer Adresse, die durch den Wert "eines Pseudoregisters be- 
stimint wird 



15 



20 



OPrCODE 

sirr 

ASSIGN 
OASSIGN 

cvr 

NMCJ. CMPL, BSWAP 
ADD. SUB, MUL, DIV, 
REM 

AST.. ASR 
LSR 

BAND, BOR, BXOR 
1{Q. Nit. LT, LE, GT,GE 

TEST/., TESTNZ 

('MP 



BESCHREIBUNG 

Setzt einen unmittelbaren Wert in ein Pseudoregister 
Bewegt den Wert in einem Pseudoregister in ein anderes Pseudoregister 
SpezielleMarkerinstruktion, die zeigt, wo Pseudoregister uberlappen, urn ein Aliasing 
explizit zu machen 

Ein Pseudoregister von einem Typ in einen anderen konvertieren (z. B. Zeichenerwei- 
terung, Nullerweiterung) 

Unare Negation, logisches Kornplement, Byte- Swap 

Binares Addieren, Subtrahieren, Multiplikation, Dividieren, Rest 

Arithmetische Verschiebung links, rechts 
Logische Verschiebung rechts 
Binares logisches Und, Oder, Xoder 

Vergleicht zwei Eingabeoperanden und setzt Ausgangsoperanden auf wahr, wenn opl 
= = op2, opl != op2, opl < op2, opl < = op2, opl > op2, opl > = op2 
Vergleicht zwei Eingabeoperanden und setzt Ausgangsoperanden auf wahr, wenn 
(opl & op2) = = 0, (opl & op2) ! = 0 

Vergleicht zwei Eingabeoperanden und setzt Ausgangsoperanden auf-1, wenn opl < 
op2, auf 0, wenn opl = = op2, und auf 1, wenn opl > op2. Dies wird aktuell vom 
OOCT nicht verwendet. 



40 OlM'ODK 

LOAD 
STORJi 
GCALL 
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55 



ICALL 

KXTT 

ENrRY 

SYNC 

HXTMOD 

sfixx: 



BESCHREIBUNG 

Laden eines Pseudoregisters mit einem Wert aus einer speziflzierten Speicherstelle 
Speichem des Werts eines Pseudoregisters in eine spezifizierte Speicherstelle 
Fuhrt einen Funktionsaufruf an eine von einem Satz vorherbestimmter globaler Funk- 
tionen durch 

Fuhrt einen indirekten Funktionsaufruf durch, ahnlich IGOTO 

Ausgang aus dern kompilierten Block. Dies wird derzeit vom OOCT nicht verwendet. 
Markiert einen Punkt, wo die Steuerung in den RuBgraphen einspringen kann. 
Markiert die Punkte, wo ein Satz von Pseudoregistem in den Speicher geraumt wird 
Markiert ein Pseudoregister als extern modifiziert. Dies wird verwendet, um eine Mo- 
difikation von Pseudoregistem durch Funktionsaufrufe zu behandeln. 
Setzt einen Booleschen auf den Wert eines Bedingungscodes auf der Basis einer Ope- 
ration. Dies wird eingesetzt, um Platze zu reprasentieren, wo Flag gen verwendet wer- 
den. Derzeit werden alle SETCC-Operationen in den Nachfolger gefaltet, so daB sie. 
nicht emittiert werden, aber die Verwendung von SETCC macht den FluB des Werts 
des Bedingungscodes expliziert, ohne daB der Kompilierer 104 mehrfache Ziele fur 
eine einzelne EL-Operation reprasentieren muB. 
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SPEZIELLE IL-OP-CODES 

Die OOCT-IL enthalt einige OP-Codes, die spezielle Zwecke haben. Die meisten EL-OP-Codes entsprechen dem 
Code, der im hinteren Ende generiert wird. Statt dessen arbeiten diese speziellen Instruktionen als Wegweiser fur den 
Kompilierer 104, daB etwas Spezielles geschieht Die IL enthalt die folgenden speziellen OP-Codes: ENTRY, SYNC, 
EXTMOD und OASSIGN. Dieser Abschnitt diskutiert die ersten drei dieser OP-Codes. OASSIGNs werden nachstehend 
umfassend erlautert. 

Der OP-Code ENTRY markiert einen Punkt, wo die Steuerung in den FluBgraphen einspringen kann. Der vom OOCT 
generierte Code kann mehrfache exteme Einsprungpunkte aufweisen, die externe Verbindungspunkte reprasentieren. Je- 
der der extemen Einsprunge hat eine entsprechende ENTRY IL-Instruktion. Die ENTRY-Instruktionen u*eten am Ende 
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des Codes auf und werden unnflHr von einer GOTO-Instruktion geiblgi, die zu e^^Rprungmarke innerhalb des 
Hauptruinpfes des Codes springt 15er Orunct daB ein Einsprung verwendei wird, anstalt daB derexierne Einsprung direkL 
zur Sprungniarke springen gclassen wird, ist, es dcm Codegeneralor zu ermoglichen, Fullzeichen zwischen ENTOY und 
dem Sprung zur Sprungniarke einzutiigen. 

Fig. 14 vejranschaulichi eine Uhersichl iiber einen Code mil zwei extemen Einsprungpunkten, wo Fullzeichen zwi- 5 
schen der ENTRY-Inslruktion und der GOTO-Instruktion eingefugi wurdcn. Mil anderen Worten veranschaulicht Fig. 14 
insbesondere ein Einsprungbei spiel geniaB einer Ausfuhrungsform der vorliegenden Erfindung. 

Der OP-Code SYNC wird verwendet, um zu garantieren, daB ein Bereich von Pseudoregistern in den Speicher ge- 
raumt wird. Insbesondere verwendei der OOCT den OP-Code SYNC, um zu garantieren, daB alle K-Register in den 
Spei criers te lien sind, wo der Interpreiicrer 110 sie zu finden erwariet. Der SYNC arbeirci als Direktive fur den Register- io 
zuordner, wobei sie anzeigt, daB ein Pseudoregister, das sich in einen i Maschinenregislcr befindel, welches modifiziert 
wurde, geleert werden sollte. Ein SYNC arbeilet auch als Verwendung aller lebendigen Daten, was verhindert, daB der 
Kompilierer 104 einen foten Code eliminiert, der nur den Efl'ekt hat, K-Register zu modifizieren. 

Der OP-Code EXTMOD wird verwendet, um anzuzeigen, daB ein Pseudoregister modifiziert ist, der Kompilierer 104 
verfugt jedoch uber keine Einzelheiten dariiber, wie das Register modifiziert wurde. So hat der EXTMOD zwei Effekte. 15 
Erstens arbeitet er als Barriere gegen Optimierungen wie Constant Folding oder Copy Propagation. Zweitens zwingt er 
den Regis terzuordner des Kompilierers 104 dazu, Fullzeichen vor der nachsten Verwendung des Pseudoregisters einzu- 
fUgen. Im OOCT werden EXTMOD-Instruktionen nach einem Riickruf zum Interpretierer 110 verwendet, um anzuzei- 
gen, welche K-Register modifiziert worden sein konnen. 

20 

IL-D ATENSTRI JKTT JREN 

Vor der Diskussion, wie die IL aus den K-OP-Codes aufgebaut wird, ist es niitzlich, die im Kompilierer 104 verwen- 
deten Hauptdalenstrukturen zu kennen. 

25 

ZONE (compiler/zone. [h,c]) 

Die Speicherzuordnung im Kompilierer 104 wird mit einer ZONE genannten Abstraktion behandelt. Die ZONE-Ab- 
straktion ist ein effizienter Weg zur Speicherzuordnung, so daB er sofort freigegeben werden kann. Mit der ZONE- Ab- 
straktion ist die Zuordnung schnell, und der Programmierer muB sich keine Sorgen iiber Speicherlecks machen, da eine 30 
Zerstdrung der ZONE den gesamten verwendeten Speicher erneut beansprucht.2 

Im Kompilierer 104 wird eine ZONE geschaffen, und alle Aufrufe, die Speicher zuordnen (d. h. was normalerweise 
maltoc- Aufrufe waren), rufen ZONE_AUoc mit der anfanglich geschaffenen ZONE auf. Wenn der Kompilierer 104 fer- 
tig ist, ruft er ZONE_Destroy auf, was die Zuordnung der gesamten ZONE riickgangig macbt (d. h. aquivalent zu einem 
Freimachen fur den gesamten Speicher). 35 

Die zugrundeliegende Implementation der ZONE verwendet 'Stucke' des Speichers. Wenn die ZONE geschaffen wird, 
kann sie an einem Block mit einer GroBe von 0 x 2000 Bytes 'malloc' ausfuhren. Aufrufe von ZONE_AUoc verwenden 
dieses 'Stuck' des Speichers, bis es verbraucht ist. Wenn kein Platz ist, eine ZONE_Alloc-Anforderung mit den anfang- 
lichen 0 x 2000 Bytes zu bedienen, wird ein neues 'Stuck geschaffen. Weitere ZONE_Alloc- Aufrufe verwenden dieses 
'Stuck', bis es auch verbraucht ist. 40 

Im Kompilierer 104 sind die Dinge durch die Tatsache, daB der gesamte Speicher vor-zugeordnet ist, etwas kompli- 
ziert, und so kann malloc nicht aufgerufen werden. Statt dessenwird eine spezielle ZONE-Zuordnereinheit (die ZAL- 
LOC-Einheit) verwendet. Der ZONE-Zuordner wird mit einem groBen Speicherpool intiualisiert (beispielsweise 0 x 
10 000 Bytes). Er teilt den Speicher in Stucke mit gleicher GroBe, welche die ZONE zur Zuordnung verwendet, und be- 
halt eine Liste freier Stucke. So werden die 'malloc'-Anforderungen durch einen Aufruf von ZALLOC_get_chunk er- 45 
setzt, der ein freies 'Stuck' Speicher zuruckgibt. Ahnlich werden die Aufrufe zur Treigabe' in ZONE_Destroy durch Auf- 
rufe von ZALLOC_free_chunk ersetzt. In der aktuellen Implementation ist die maximale ZuordnungsgroBe, die von ZO- 
NE_AUoc behandelt werden kann, die anfangliche StiickgroBe. Diese Grenze konnte durch die Anderung der ZALLOC- 
Einheit 'festgelegt* werden, um Zuordnungen van abler GroBe zu behandeln, anstatr einfach eine GroBe zu behandeln 
(siehe Segmentzuordnungseinheit fur ein Bei spiel dieses TVps eines Zuordners). Es gibt zwei Griinde, warum dies hier 50 
nicht durchgefuhrt wurde. Erstens ist ein Zuordner mit variabler GroBe viel komplexer und schaflft Probleme wie eine 
Fragmentierung. Zweitens kann die SluckgroBe mit wenig bis gar keinen EinbuBen sehr groB gemacht werden. Wenn das 
Stuck ausreichend groB ist, fordert der Kompilierer 104 nur eine einzelne Zuordnung an, die groBer ist als die Stuck- 
groBe, wenn der Kompilierer 104 sowieso keinen Speicher mehr gehabt hatte. So gibt es keinen echten Vorteil bei der 
Generalisierung der ZALLOC-Einheit, um Zuordnungen mit variabler GroBe zu behandeln. 55 

IL_CTXT (compiler/oc_commori/include/il_internal.h) 

Der Kompilierer 104 halt eine einzelne Daten struktur, die IL_CTXT, um den aktuellen Zustand der Kompilierung zu 
verfolgen. Die TTv_CTrXT-Dat en struktur speichert einen Zeiger zu einer verketteten T.iste von TT._NODEs, die den aktuell 60 
kompilierten Code reprasentieren. Die IL_CTXT speichert auch eine Anzahl verschiedener Felder, die wahrend des ge- 
samten Kompilierungsprozesses verwendet werden, wie die ZONE- und IL_FRAME-Struktur, die verwendet werden. 
Jede der Stufen des Kompilierers 104 hat die IL_CTXT als Argument und nimmt an dieser Datenstruktur Modifikationen 
vor, beispielsweise eine Anzahl der Stufen addieren, oder IL_NODEs entfernen. 
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IL_NODE (compiler/oc__common/include/il_internal.h) 
Die IL_NODE-Daten struktur reprasentiert eine einzelne abstrakte Instruktion in der Zwischensprache des Kompilie- 
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rers 104, wie aus eineni l^^^Codc iiberselzt. 

Die IL_NODES, die aus den K-OP-Codes generierl werden, werdcn in einer doppelt verketteten Lisle gehalten. Zciger 
auf die erslen und letzlcn Elcmenie in dieser Lisle werden in der IL_C7rXT gehalten. Diese Lisle reprasentiert den Code, 
an dem der Konipilierer 104 akiuell arbeilel. Jeder Durchlauf des Kompilierers 104 quert diese Lisle und generiert ent- 
s weder Inform at ionen tiher den Code in der Lisle oder transformiert die Liste. 

Jede IL NODE en thai! ein Operalionsfeld 'op', das die Grundbeschaffenheil der Instruktion anzeigl. Sie cnthall auch 
einen Vektor von Operandenfeldem, welche die Operanden der Instruktion reprasenlieren. Die Interpretation der Ope- 
randenfelder ist voni Operationslyp der Instruktion abhangig. Zusalzlich zu den Operations- und Operandenfeldem ent- 
halten alle IL_NODEs eine Anzahl von Feldern, die von alien Knoieniypen gemeinsam genutzt werden, wie K pc der ln- 
i » sirukuon, aus welcher der Knoten ubersetzt wurde, die Startadresse des fur den Knoten generierten Zielmaschinencodes, 
etc. 

Die Anzahl von Operandenfeldem in eineni Knoten variiert gemaB dem Operationstyp. Tatsachlich konnen in einigen 
J :illen zwei Knoten desselben Typs eine verschiedene Anzahl von Operanden aufweisen; die Anzahl von Operanden fur 
cine Aufrufoperation ist beispielsweise von der Anzahl von Argumenten abhangig, die zum Zielverfahren weitergereicht 
i ^ u urden. Diese Variation der Anzahl von Operanden bedeulet, daB IL_NODEs keine konsistente Gr66e aufweisen, und 
Anti der Operandenvektor das letzte Element in der IL_NODE-Struktur ist. Der Operandenvektor wird als einen Eintrag 

I. mi! dekJariert, und IL_NODES werden durch die Berechnung/Zuordnung des gesamten Speicherbetrags, der fur die ge- 
mcinsainen Felder und die Operandenfelder notwendig ist, und durch das Umformen des zugeordneten Speichers zu ei- 
neni IL_NODE-2!^iger zugeordnet. 

• . In den meisten, jedoch nicht in alien Fallen erfordert jeder Operand tatsachlich zwei aufeinanderfolgende Eintrage im 
( )| vrundenvektor. Der Eingangsoperand [i] des Pseudoregisters, in dem der Operand zu finden ist. Wenn der Operand ein 
/.ic (operand ist, zeigt Operand[i+l] zu einer Liste von Knoten, die den Wert verwenden, der von dieser Operation defi- 
nicri wird; wenn der Operand ein Quellenoperand ist, zeigt Operand [1+1] zu einer Liste von Knoten, die Definitionen fur 
den Wert enlhalten. 

^ Wenn eine Operation einen Zieloperanden aufweist, wird dieser Operand immer in Operand[0] und Operand[l] ge- 
sjK-icheri. 

Wenn Opcrand[i] ein Qucllcn-(Eingangs- oder vcrwcndungs-)opcrand ist, ist dies auch Opcrand[i+2]; d. h. alle 'Quel- 
lenregister miissen an das Ende der Liste der Operanden kommen. 

Auf Operandenfelder in eineni Knoten wird niemals direkt zugegriffen. Der Zugriff erfolgt eher durch einen groBen 
v» S:it/. von Makros in Form von ILOP_xxx(N), wobei N ein Zeiger zu einer IL_NODE ist. Diese Makros wissen, wie ver- 
schiedene Operanden im Operandenvektor fur alle verschiedenen Instruktionstypen gespeichert werden. 

liinige der Knotentypen sind wie folgt (diese Liste ist nicht vollstandig): 

Unare Operationen 

;s 

Diese represent ieren eine Varietat einfacher unarer (1 Quellenoperand) Instruktionen, die eine Zuweisung enthalten. 
Ty P 

der 'IVp der Operation 
FLOP DEST(N) 
4i> /.ic I register; wo das Result ai hingeht 

II. OP DEST.use(N) 

Liste von Instruktionen, die das '/ielregister verwenden 
ILOP.SRC(N) 
Quellcnregister 
4> ILOP.SRC def(N) 

Lisle von Instruktionen, welche die Quelle definieren 

Binare Operationen 

S« Line groBc Anzahl binarcr (2 Quellenoperandeh) Instruktionen werden von dieser Kategorie reprasentiert. 
'IVp 

der Typ der Operation 
ILOP DEST(N) 

Zielregister; wo das Result at hingeht 
55 rU3P_DEST_use(N) 

Liste von Instruktionen, die das Zielregister verwenden 

ILOP_SRCl(N) 

crsles Quellenregister 

ILOP_SRCl_def(N) 
60 Liste von Instruktionen, welche die erste Quelle definieren 

ILOP_SRC2(N) 
zweites Quellenregister 
ILOP_SRC2_def(N) 

Liste von Instruktionen, welche die zweite Quelle definieren 
65 ILOP_DIVEX(N) 

Dieser Operand tritt nur fur die DI V- und REM-Operationen auf, und zeigt auf eine (Singleton) Liste, die den Knoten ent- 
halt, der den Start der Nullteilungsausnahme reprasentiert, sofern eine vorliegt. 
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LABEL 

Einc LABEL-Inslruklion reprasentiert einen Punkt. im Code, wohin sich Verzwcigungen verzweigen konnen. Sic ent- 
haJl die folgenden Operanden: 

ELOP_LABEL(N) 5 

Eindculige ganze Zahl, welche die Sprungmarke (engl. label) identifiziert. 

ILOP_LABEL_rels(N) 

Liste von Instruktionen, die auf diese Sprungmarke bezugnehmen 
LLOP_L AB EL_li ve(N ) 

BITSET, der zeigt, welche Regis ler an dieser Sprungmarke lebendig sind. 10 
ELOP_LABEL_rd(N) 

Vektor von Listen der Definitionen jedes Registers, der diese Sprungmarke erreicht. 
TLOP_LABET ._misc(N) 

Platz fur jeden Durchlauf, um private Informationen iiber die Sprungmarke anzuhangen. 



GOTO 



CGOTO 



15 



Eine GOTO-Instruktion reprasentiert eine unbedingte Verzweigung zu einer Sprungmarke. 
ILOP_LABEL(N) 

: Eindeutige ganze Zahl, welche die Zielsprungmarke identifiziert. 20 
ILOP_LABEL_refs(N) 

Singleton-Liste der Ziel-LABEL-Instruktion. * 
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Eine CGOTO-Inslruktion reprasentiert eine bedingte Verzweigung zu einer Sprungmarke. Sie enthalt dieselben Ope- 
randen wic die GOTO-Instruktion sowic cinigc zusatzlichc Operanden. 
ILOP_COND(N) 

Register, das die Bedingung enthalt, bei der zu verzweigen ist. Dieses Register muB einen Wert vom Booleschen (Bl) 
Typ enthalten. Die Verzweigung wird eingeschlagen, wenn die Bedingung TRUE ist. 30 
ILOP_COND_def(N) 

Liste von Instruktionen, die dieses Register definieren. 
ILOP_COND_live(N) 

BITSET, der zeigt, welche Register lebendig sind, wenn die Verzweigung nicht eingeschlagen wird. 

Zusatzlich zu den instruktionsspezifischen ILOP-Makros gibt es eine Anzahl generischer Makros, die bei jeder In- 35 
struktion verwendet werden konnen. 
ILOP.HasDEST 

Gibt TRUE (WAHRT) zuriick, wenn die Instruktion ein Zielregister aufweist. In diesem Fall konnen die ILOP_DEST- 
und ILOP_DEST_use-Makros bei dieser Instruktion verwendet werden. 

IL_OP_START, EL_OP_DONE, IL_OPNEXT 40 
Werden zur Iteration durch die Quellenregister einer Instruktion verwendet. IL_OP_START fuhrt einen TL_OP_INDEX 
zuruck, der auf das erste derartige Quellenregister bezugnimmt. IL_OP_DONE testet einen IL_OP_INDEX, um zu se- 
hen, ob er auf ein Quellenregister bezugnimmt; true wird zuriickgefuhrt, wenn dies nicht der Fall ist. EL_OP_NEXT wird 
verwendet, um zum nachsten Quellenregister weiter zu gehen. 

IL_OP, IL_OP_def 45 
Diese fuhren das bestimmte Quellenregister und die Definitionsliste dafiir fiir einen gegebenen IL_OP_INDEX zuruck. 
Diese 5 Makros werden allgemein in einer Schleife der Form verwendet: 

for (op=IL_OP_START(n); !IL_OP_DONE(n,op); op=IL_OP_NEXT(n,op)) {use IL_OP(n, ILJFRAME (compiler/ 
oc_common/include/il_frame.h, compiler/OOCT_Frame.c). 

Die IL_FRAME-Datenstruktur wird verwendet, um Informationen iiber den Kontext zu geben, in dem der kompilierte 50 
Code laufen wird. Der Rahmen bzw. engl. frame definiert die GroBe und Speicherstelle fiir jedes der PseudoregiSter, wie 
die Pseudoregister andere Pseudoregister iiberlappen, und welche Maschinenregister im Registerzuordner legal zu ver- 
wenden sind. Zusatzbch definiert die IL FRAME-Struktur, ob ein C-Stapelrahmen fiir den Code, der kompibert wird, er- 
forderlich ist oder nicht. Im OOCT werden keine C-Stapelrahmen verwendet. 

Im Kompilierer 104 wird die IL_FRAME-Struktur durch die Funkdonen in OOCT_Frame.c aktualisiert. Diese Funk- 55 
tionen erstellen jedes der Pseudoregister, die den K-Registern und PSW-Stellen entsprechen. Ferner werden die tempo- 
raren Pseudoregister des Kompilierers 104 so gesetzt, daB sie dem Arbeitsraumbereich des Interpretierers 110 entspre- 
chen. Es werden auch Informationen dariiber erstellt, wie die K-Register einander iiberlappen. 

NT._TJST (compiler/oc_common/[include, src]/nl_nodelist..h) 60 

An vielen Platzen verwendet der Kompilierer 104 Listen von IL_NODEs, die NL_LIST-Datenstruktur sieht eine Ab- 
straktion fiir die Manipulation dieser Knotenlisten vor. Beispielsweise schafft die oben angegebene UseDef-Analyse Li- 
sten von IL_NODEs, die eine gegebene Definition verwenden, und Listen von IL_NODEs, welche die Definition fiir eine 
gegebene Verwendung sein konnen. Die NL_UST-Abstraktion ist geradlinig, sie sieht die Fahigkeit zum Schaffen, Ent- 65 
femen, Ersetzen, Suchen und Iterieren von Knotenlisten vor 
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K-OP-COD1I FUR DIE EL-OBERSETZl 



Nachdem der oben angegebene Blockwahler 114 gcwahlt hat, welche K-OP-Codes zu kompilicren sind, involviert die 
Ubersetzung der K-OP-Codes in die IL drei Hauptschritle. Der ersle SchriH ist die Beslimmung der Reihenfolge, in wel- 
5 cher der Code fur die Basisblocke gencriert wird. Das Blockaufbauverfahren ist vorstehend angegcben. Zweitens, wah- 
rend die Basisblocke der K-OP-Codes durch das Blockaufbauverfahren gewahlt werden, werden die OP-Codes unter- 
sucht, uni zu bestimmen, ob sie in einen 'logischen OP-Codc' konibinierl werden konnen. SchheBlich wird eine EL-Ge- 
nerierungsprozedur auf der Basis des K-OP-Codes und seiner Argumente aufgerufen. 

10 Opcode Combination (coinpiler/oocl_opcode_coinbine.c) 

Einige Sequenzen von K-OP-Codes konnen als einzelner logischer' OP-Code beschrieben werden. Beispielsweise 
wurde bestimmt, daB eine Sequenz von zwei TR-Tnstrukrionen zum Testen des Werts eines 32 Bil-Regislerpaares durch 
das Teslen jeder der einzelnen Halften verwendet wurde. Diese beiden TR-Instruktionen reprasentiercn einen logischen 

15 32 Bit-Test-OP-Code, der in der K-Architektur nicht verfugbar ist. Der Code, den die IL-Aufbauprozeduren fur die bei- 
den TR-Instruktionen schaffen wiirden, ist viel weniger effizient als der Code, der geschaffen werden konnte, wenn die- 
ses Muster erkannt werden wurde. Da der OOCT-Software ist, ist es glucklicherweise einfach, einen neuen OP-Code hin- 
zuzufugen, eine spezielle Einbeit, welche die Muster erkennt, zu haben und start dessen die effiziente IL zu generieren. 
Vor der Generierung der Standard-XL fur einen gegebenen OP-Code wird die Routine OOCT_opcode_combine aufge- 

20 rufen. Diese Routine wiederhoit alle Muster, die definiert wurden, wobei sie versucht, einen 'logischen* OP-Code zu ver- 
wenden, wenn er geeignet ist. Derzeit sind nur zwei Muster definiert, es ist jedoch geradlinig, zusatzliche Kombinationen 
zu definieren. Wenn eines der Muster ubereinstimnit, wird die IL-Aufbauprozedur fur diesen logischen OP-Code ver- 
wendet, um die IL-Instruktionen zu schaffen, und OOCT_opcode_combine fuhrt TRUE zuruck, um anzuzeigen, daB die 
normale IL-Aufbauprozedur nicht aufgerufen werden muB.3 

25 

TLJBuilding Procedures (compiler/oocl_il_build.c) 

Fur jeden K-OP-Code gibt es eine spezifische EL-Aufbauprozedur. Die IL-Aufbauprozeduren verwenden zwei Typen 
von. Argumenten, die Adresse der Instruktion, und eine Liste von Argumenten, die sich in den Feidem in der Originalin- 

30 struktion befinden. Die IL-Aufbauprozeduren verwenden auch einen gemeinsam genutzten, globalen variablen glo- 
bal_gen_state, der verwendet wird, um die Pseudoregister und Sprungmarken wahrend der Generierung der IL zu ver- 
folgen. Jede der IL-Aufbauprozeduren fugt IL-Instruktionen zur IL_CTXT-Struktur hinzu. Alle der IL-Generierungsrou- 
tinen schaffen einen LABELJQL_NODE rnit der Adresse der Originahnstruktion als Identifikator der Sprungmarke 
(wenn die Sprungmarke nicht das Ziel einer anderen Instrukuon ist, wird sie friih im OptimierungsprozeB eliminiert), es 

35 wird jedoch nicht allgemein versucht, Optimierungen durchzufuhren, was spateren Kompilierer-104-Stufen uberlassen 
wird, es werden aber einige Spezialfalle behandelt, wie das Prufen auf Ausnahmen, die zur Kompilierungszeit detektiert 
werden konnen. 

Die meisten der IL-Aufbauprozeduren sind geradlinig oder direkt, sobald die EL und die Origin alinstruktion des Codes 
generiert werden, um bekannt oder vertraut zu werden. Es gibt einige lips, die helfen, den Code zu verstehen: 

40 Der IL-Aufbau wurde so ausgebildet, daB die Kompilierung irgendeines gegebenen OP-Codes ieicht fur eine Diagnose 
abgeschaltet werden kann. Dies wird hauptsachuch mil dem Makro REALLY_COMPILE und den Makros COMPI- 
LE_SECTTON_XX gesteuert. Wenn REALLY_COMPILE ausgeschaltet ist, bauen alle IL-Aufbauroutinen einfach Auf- 
rufe (oder Sprunge) zuruck zum Interpretierer 110 auf. Wenn COMPILE_SECTION_X ausgeschaltet ist, bauen alle IL- 
Aufbauroutinen fur OP-Codes im Abschnitt Nummer X einfach Aufrufe (oder Sprunge) zuruck zum Interpretierer 110 

45 auf. 

Da die IL typisiert ist, ist es kritisch, Pseudoregister mit der korrekten GroBe mit dem korrekten Typ zu verwenden. 
Um beispielsweise einen 16 Bit- Wert in ein 32 Bit-Register zu laden, wird zuerst eine 16 Bit-Ladung in ein 16 Bit-Pseu- 
doregister vorgenommen, und dann wird eine CVT-Operation verwendet, um den 16 Bit- Wert in einen 32 Bit- Wert um- 
zuformen (das Makro LOAD_CVT32 tut dies). 

50 Wann immer ein Riickruf oder Sprung zum Interpretierer 110 eingefugt wird, muB SYNC hinzugefiigt werden, um si- 
cherzustellen, daB der Interpretierer 110 die korrekten Werte fur die K-Register aufweist. Der kompilierte Code versucht 
nicht, den Wert des ESI-Registers zu halt en, wie es geht (tatsachlich wird er verwendet, um andere Werte zu halten). So 
muB der generierte Code vor einem Aufruf oder Sprung zum Interpreuerer 110 den korrekten Wert in das ESI-Register 
setzen. Wenn ein Ruckruf erf olgt, muB der Code auch eine EXTMOD-Instruktion fur jedes Pseudoregister enthalten, das 

55 vom Ruckruf modifiziert worden sein kann (das Makro MODIFIES_REG tut dies). 

Ein Code zur Behandlung von Ausnahmebedingungen (wie Uberlaur) ist nicht ausgerichtet. Statt dessen wird der 
Code am Ende der Liste von IL-Instruktionen generiert. Dadurch kann der allgemeine Fall als Fehlschlag kompiliert wer- 
den, was typischerweise die Leistung des generierten Codes verbessert. 

60 Einsprungpunkte, Unterbrechungsprufungen 

Zusatzlich zur IL, die fur jeden vom Blockwahler 114 gewahlten K-OP-Code generiert wird, wird eine IL fur Ein- 
sprungpunkte, Unterbrechungsprufungen generiert. 

Um zu ermoglichen, daB mehr Optimierungen eintreten, wird jedes Verzweigungsziel nicht als externer Einsprung- 
65 punkt eingeschlossen (externe Einsprungpunkte arbeiten als Barriere fur Optimierungen). Insbesondere sind die einzigen 
Ziele, die zu externen Einsprungpunkten gemacht werden soli ten, jene, zu denen Yon auBerhalb des Segments gesprun- 
gen wird. Wenn ein gegebenes Segment kompiliert wird, sind Teilinformationen dariiber im Verzweigungsprotokoll ver- 
fugbar, welche Ziele dieses Kriterium erfullen (fur Informationen iiber das Verzweigungsprotokoll siehe oben); Der 

30 
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Kompilierer 104 verwendet diese^^^nialionen, uni zu wahlen. welche Basisblocke e^Um Einspriinge haben solllen. 
Fur jeden dieser Einspriinge wird eine ENTRY EL_NODE zusamnien mil eincr GOTO TL_NODE generiert, dcr zur ge- 
nerierten IL fiir die Originaleinsprunginstruktion spring!. 

Die OOCT-Spezifikationen zeigen an, daB dcr Kompilierer 104 Unterbrechungspriifungen innerhalb irgendeiner 
Schleife einfiigen sol he. Wenn die EL generiert wird, wird eine konservative Schatzung gemacht, indem Unterbrechungs- 
priifungen innerhalb jeder Ruckwarls-Verzweigung innerhalb des Segments und vor irgendeiner berechneten Sprungin- 
siruktion eingefugt werden. Die Unterbrechungsprufung wird nach der Sprungmarke fur die letzte Originalinstruktion im 
Basisblock eingefugt. Wie bei anderen Ausnahmebedingungen wird der IL-Code fiir die Unterbrechung nicht ausgerich- 
tet generiert, so dati der Normalfall einfach der Fehlschlag der bedingten Verzweigung ist. 

BESCI IREIBUNG DES MITTLEREN ENDES DES KOMPILIERERS 

UBHRBT JCK UBHR DAS MTTTLERR HNDH 

Der Hauptzweck des 'mittleren Endes' des Kompilierers 104 ist die Verbesserung der Qualitat der IL, so daB ein bes- 15 
serer Code in der Codegenerierungsstufe generiert wird. Der Rest des Kompilierers 104 ist als Serie von Durchlaufen 
strukturiert, die entweder eine Analyse der IL durchfiihren, Oder eine Transformation durchfuhren, welche die IL modi- 
fizierL Die Durchlaufe konnen mehrfache Male angelegt werden, obwohi es einige Abhangigkeiten zwischen Durchlau- 
fen gibt. Ab diesem Punkt hat der Rest des Kompilierers 104 keinc besondere Kenntnis von K-Instruktionen, er hat nur 
emit der IL zu tun. 20 
■■■■■ Der Rest dieses Abschnitts ist wie folgt unterleilt. Als erstes wird die Stufe diskutiert, welche die OASSIGN-Einfu- 
gung vornimml. Als zweites werden Analysedurchlaufe des Kompilierers 104 diskutiert. SchlieBlich werden Transfor- 
mation sdurchlaufe (welche die Hauptoptimierungen vornehmen) des Kompilierers 104 diskutiert. 

Fig. 15 veranschaulicht teilweise ein OASSIGN-Einftigungsbeispiel. 

25 

OASSIGN INSERTION (compUer/oocl_add_overlap_defs.c) 

Der OASSIGN-OP-Code ist eine spezielle Markerinstruktion, die ein Aliasing zwischen Pseudoregistern explizit 
macht. Die Notwendigkeit von OASSIGN entsteht im OOCT, da einige K-OP-Codes 16 Bit-Register verwenden, wah- 
rend andere Operationen 32 Bit-Register verwenden, welche als Alias der 16 Bit-Register fungieren. Im OOCT werden 30 
getrennte Pseudoregister fur aile der 16 Bit- und 32 Bit-Register verwendet. So uberlappen einander einige der Pseudo- 
register implizit. Dies schaffl zwei Probleme. Das erste Problem betrifft Optimierungsdurchlaufe, die inkorrekte Trans- 
formationen vornehmen. Fiir jede Pseudoregisterdefinition verfolgt der Kompilierer 104 die Instruktionen, die diese De- 
finition verwenden, und fiir jede Pseudoregisterverwendung verfolgt der Kompilierer 104 ihre Definitionen. Diese Infor- 
mationen werden use/def-Informationen genannt. Der Kompilierer 104 verwendet use/def-Informationen in Durchlaufen 35 
wie dem Constant Folding-Durchlauf. Wenn Pseudoregister als Alias fureinander fungieren konnen, erfordert dies die 
use/def-Berechnung, und der Kompilierer 104 reicht diese "use" dieser Informationen weiter, urn viel komplexer zu sein. 
Ein zweites Problem, das durch iiberlappende Pseudoregister geschaffen wird, liegt in der Registerzuordnung. Wenn der 
Registerzuordner gleichzeitig zwei iiberlappende Pseudoregister Maschinenregistern zuweist, kann eine Modification ei- 
nes Registers erfordern, daB das andere Register ungiiltig gemacht wird. Allgemein ist die Verfolgung dieser Informatio- 40 
nen sehr schwierig und schafft eine unndtige Komplexi tat. 

Anstatt diese schwierigen Probleme anzugehen und signifikarit zur Komplexi tat des Kompilierers 104 beizutragen, 
wurde ein Verf ahren zum Einfugen spezieller Marker-OASSIGN-Instruktionen ausgebildet, das es dem Kompilierer 104 
ermoglichen wurde, das Problem zu ignorieren. Ein spezieller Kompiliererdurchlauf unmittelbar nach der IL-Generie- 
rung fiigt OASSIGNs ein. Nach diesem Kompilierer- 104-Durchlauf wird anderen Analysedurchlaufen gestattet anzu- 45 
nehmen, daB Pseudoregister einander nicht uberlappen (in bezug auf die use/def- Analyse). Ferner ist die Registerzuord- 
nung unter Verwendung von OASSIGNs ziemlich einfach zu behandeln. Wann immer der Registerzuordner zu einem 
OASSIGN kommt, leert er die Quelle an ihrer Definition und fullt das Ziel nach dem OASSIGN ein. Dieses Verfahren 
verwendet den Alias-Speicher, um zu garantieren, daB jede Verwendung der Uberlappungsdefinition den korrekten Wert 
verwendet. 50 

Die OASSIGN-Einfugung wird in zwei Stufen behandelt. Zuerst wird eine spezielle Version der UseDef-Analyse lau- 
fen gelassen. Diese Version von UseDef kennt Pseudoregisteriiberlappungen, und schafft Verwendungslisten und Defi- 
nitionshsten, die uberlappende Pseudoregister enthalten. Der Rest des Kompilierers 104 ist nicht vorbereitet, use/def-Li- 
sten zu behandeln, die uberlappende Pseudoregister enthalten, daher sollte diese Option fur UseDef allgemein nicht ver- 
wendet werden. Nachdem diese Analyse vorgenommen wurde, nimmt die Prozedur OOCT_Add_Oyerlap_Defs die tat- 55 
sachliche Einfiigung von OASSIGNs vor. OASSIGN wird fur jede Verwendung eingefugt, die eine Uberlappungsdefini- 
tion aufweist (d. h. eine Definition, die ein Pseudoregister definiert, welches das Pseudoregister der Verwendung Uber- 
lappt), und fiir eine Uberlappung erreichende Definitionen an Sprungmarken. 

Fig. 15 veranschaulicht ein Beispiel eines Falls, wo OASSIGN eingefugt werden wurde. In dem Beispiel uberlappen 
einander die Pseudoregister GRPAIR1 und GR1 , so daB die Zuweisung zu GRPATRl in der ersten Zeile des Codes eine 60 
implizite Modification von GR1 ist. OASSIGN macht dies explizit. 

ANALYSEDURCHLAUFE 

UseDef (compiler/oc_common/src/oc_usedef.c) 65 

Die Berechnung der Verwendungen einer gegebenen Definition und der potentiellen Definitionen fiir eine gegebene 
Verwendung ist eine der grundlegendsten Kompilierer-104-Analysen. Jeder Kompilierer-104-Optimierungsdurchlauf 
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verwendet die use/def-Inl^malionen. Jede der IL-Inslruktionen kann ein PseudoBPsterargument, das (in ein Ziel) ein- 
geschriebcn wird, und eines Oder niehrere Pseudoregisterargumenie, die (aus einem src) ausgelesen werden, aufweisen. 
Nach der TJseDef- Analyse hat jedes Ziel eine daniii assoziierte Liste, die Zeiger auf allc IL-Instruklionen speichert, wel- 
che diesen Wert verwenden konnten (du chain genannt). Ahnlich hat jedes src eine damit assoziierte Liste, die allcEL-In- 
S struklionen speichert, welche diesen Wert definieren (auch ud chain genannt). Das Verfahren zur Berechnung der use/ 
def-Informalionen wird nachslehcnd beschrieben. Es ist ein ileralives Verfahren, das versucht, einen festgeleglen Punkl 
zu erreichen (d. h. bis weitere Ilerationen keine Anderungen mehr durchfiihren). 

Die folgcnden Schritte wiederholen, bis es zu keiner Anderung der erreichenden Definitionen an irgendeiner Sprung- 
niarke mehr koninit. 

m Die Definitionsliste fur jedes Pseudoregister in regdefs (ein Array von NL-LISTs, indexiert von einem Pseudoregister) 
loschen. 

Uber die ILJSIODEs in statischer Programmreihenfolge iterieren. 

Wenn die Instruktion ein Pseudoregister verwendet, die Definition des Pseudoregisters aus regdefs zur ud chain des 
Operanden kopieren. 

15 Wenn die Instruktion eine Verzweigung ist, die regdefs nut den erreichenden Definitionen kombinieren, die im LA- 
BEL der Verzweigung gespeichert sind. Anderungen der erreichenden Definitionen verursachen, daB die gesarnte 
Schleife wiederholl wird. 

Wenn die Instruktion ein LABEL ist, die regdefs mit den erreichenden Definitionen bereits am LABEL kombinieren. 
Wenn die Instruktion ein Pseudoregister definiert, die Definitionsliste in regdefs so setzen, daB sie nur diese Instruktion 
20 enthalt. 

Wenn die Instruktion eine unbedingte Verzweigung ist, das regdefs Array andera, damit es der Satz von erreidhenden 
Definitionen ist, die am nachsten LABEL gespeichert sind. Dies wird durchgefuhrt, da die Instruktionen in ihrer stati- 
schen Reihenfolge verarbeitet werden, und die Definitionen, welche die unbedingte Verzweigung erreichen, nicht diesel- 
ben sind wie jene, die ihren statischen Nachfolger erreichen. 



Live Variable Analysis (conipiler/oc_coiiuiion/src/oc_usedef.c) 



Eine. weitere Form der Analyse betrifft lebendige variable Informationen. Die lebendige Variablenanalyse wird haupt- 
sachlich zur Registerzuordnung verwendet, kann jedoch auch zur Induktion variabler Transformationen und zur Totco- 

30 deeliminierung verwendet werden. Ein Pseudoregister wird als iebendig an einem bestimmten Punkt in einem Programm 
angesehen, wenn das Pseudoregister entlang einem Ausfuhrungspfad verwendet werden kann, bevor es neu definiert 
wird. Die lebendige Variablenanalyse markiert auch die letzte Verwendung eines gegebenen Pseudoregisters (eine Ver- 
wendung ist die letzte Verwendung, wenn es keine moglichen Ausfuhrungspfade gibt, auf denen das Pseudoregister ver- 
wendet wird, bevor es neu definiert wird). Das zur Berechnung der lebendigen variablen Informationen verwendete 

35 Grundverfahren wird nachstehend erlautert. Es arbeitet, indem wiederholte Ruckwartsdurchlaufe uber den Code durch- 
gefuhrt werden, bis ein festgelegter Punkt erreicht ist. 

Die folgenden Schritte wiederholen, bis es zu keiner Anderung mehr der erreichenden Definitionen an irgendeiner 
Sprungmarke kommt. 

40 Lebendig loschen (ein Bitsatz von Pseudoregistern) 

Uber die EL_NODEs in umgekehrter statischer Programmreihenfolge iterieren. 

Wenn die Instruktion ein Pseudoregister verwendet, das Bit des Pseudoregisters lebendig setzen. 'vVfenn das Pseudore- 
gister vorher nicht lebendig war, als letzte Verwendung markieren. 
45 Wenn die Instruktion eine Verzweigung ist, lebendig mit den lebendigen Registern kombinieren, die am LABEL der 
Verzweigung gespeichert sind. Anderungen an den lebendigen Registem verursachen, daB die gesarnte Schleife wieder- 
holt wird. 

Wenn eine Instruktion ein LABEL ist, lebendig mit den lebendigen Pseudoregistern bereits an der Sprungmarke kom- 
binieren. 

50 Wenn die Instruktion ein Pseudoregister definiert, Pseudoregister aus lebendig loschen. 

Wenn die Instruktion eine unbedingte Verzweigung ist, lebendig loschen. Dies wird durchgefuhrt, da bei der Verarbei- 
tung der Instruktion in ihrer umgekehrten statischen Reihenfolge die lebendigen Variablen an der unbedingten Verzwei- 
gung nicht dieselben sind wie jene an ihrem Nachfolger. 

55 Register Allocation (compiler/c<:_cornmon/src/oc_regalloc.c) 

Die Registerzuordnung im Kompilierer 104 wird in zwei Stufen durchgefuhrt. Die erste Stufe nimmt eine Analyse des 
Codes vor, und bestirnmt einen Satz empfohlener Registerzuweisungen auf der Basis eines Modells hoherer Ordnung der 
Zielmaschine. Die zweite Stufe verwendet die Analyse von der ersten Stufe zusammen mit einem weniger abstrakten 
60 Maschinenmodell, urn den Code tatsachlich zu modifizieren, physische Register zu verwenden. Dieser Abschnitt disku- 
tiert die erste Stufe. 

Das Registerzuordnungsverfahren basiert auf der traditionellen Technik der Verwendung der Graphfarbung. Die Kno- 
ten des 'Graphen' sind lebendige Pseudoregistefbereiche, mit Kanten zwischen lebendigen Bereichen, die einander uber- 
lappen. Eine N-Farbgraphfarbung weist eine von NFarben jedem Knoten zu, so daB keine zwei verbundenen Knoten die- 
65 selbe Farbe haben. Wenn der Graph lebendiger Bereiche N gefarbt sein kann (wobei N die Anzahl verfugbarer physi- 
scher Register ist), wird klarerweise ein Register jedem lebendigen Bereich zugewiesen. Leider ist die Graphfarbung ein 
ernstes NP-Problem (d. h. es erfordert exponentielle Zeit), daher wird in der Praxis Heuristik verwendet. 

Die Registerzuordnung ist ein komplexes Verfahren mit mehreren Schritten. Die Schritte werden nachstehend detail- 
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lierl beschricben. 

1. Tcilen unabhangiger Iebendiger Bereichc und Zuordnung von REGINFO-Strukturen 

Die Funkiion CompuleReglnfo till dies. Sic teill jedes Pseudoregister in unahhangige lebendige Bereichc, und ordnet 5 
eine REGINFO-Struktur fur jeden zu. Die REGINFO-Struktur wird verwendet, um Infonnationen uber den betreffenden 
lebendigen Bereich zu halten, der fur die Regislerzuordnung verwendet wird, und hall schlieBlich das *Ziel'register - das 
physische Register, das fur den lebendigen Bereich zugeordnet wird. Da eine 1 : 1 Enlsprechung zwischen lebendigen 
Pseudoregislerbereichen (ein logisches Konstrukt) und REGINFO-Slrukturen besleht, wird der Ausdruck REGINFO oft 
verwendcL, um sich sowohl auf den lebendigen Bereich als auch auf die Datensiruktur zu beziehen. ' 10 

ConiputeReglnlb fuhrt das Teilen Iebendiger Bcreiche nahezu als NebenefTekt der Zuordnung der REGINFO-Struk- 
turen durch. Die Funktion arbeitet, indem sie mit einer Definition beginnt, die noch keine REGINFO aufweist, eine neue 
REGINFO dafur schaffl., dann rekursiv alle ihre Verwendungen und alle ihre Definifionen (und alle ihre Verwendungen 
. . .) ansieht, und die neue REGINFO mit jeder Definition UDd Verwendung, die erreichbar ist, assoziiert. 

Sobald alle REGENFOs geschaffen worden sind, werden sie in 'einfache' und 'komplexe' geteilt. Eine 'einfache' RE- 15 
GINFO: 

Hat exakt eine Definition und eine Verwendung. 
Die Verwendung folgt unmiuelbar der Definition. 

Die Verwendung ist nicht der 2. Operand einer BINOP (zielspezifischen Voraussetzung). 

Alle anderen REGINFOs sind komplex. Jede REGINFO erhalt eine eindeutige ID, wobei die komplexen im Bereich 20 
[0. .c->rLcomplex] liegen, und die einfachen im Bereich [c->ri_complex. x->ri_total] liegen. Der Zweck dieser Teilung 
ist, Speicher beim Halten der Konfliktmatrix zu sparen, die als BITSETs in jeder REGINFO gespeichert ist Der Effekt 
der obigen Definition von 'einfach' ist, daB keine zwei einfachen REGINFOs jemals in einen Konflikt miteinander treten 
konnen. 

25 

2. Berechnung von Konfliklen und Kompalibilitalen 

Der nachste Schritt ist die Berechnung des Konfliktgraphen der REGINFO-Slrukturen. Zwei REGINFOs stehen in ei- 
nem Konflikt, wenn ihre lebendigen Bereiche uberlappen. Zwei REGINFOs sind kompatibel, wenn sie durch Kopieren 
verbunden werden. In einem Konflikt stehende REGINFOs konnen nicht demselben Register zugewiesen werden, da sie 30 
gleichzeitig lebendig sind. Zwei kompatibie REGINFOs sollten demselben Register zugewiesen werden, wenn moglich, 
da dies eine Kopie eliminiert. 

Die Konflikte sind entweder als Graph (mit einem Knoten fiir jede REGINFO und einer ungerichteten Kante, die jeden 
REGINFO-Knoten mit jedem anderen Knoten verbindet, mit dem er in Konflikt stent - dies ist die Ansieht, die bei 
Graphfarbungsverfahren verwendet wird) oder als symmetrische binare Matrix vorstellbar. Diese letztere Form liegt dem 35 
naher, wie die Konflikte tatsachlich gespeichert werden. 

Jede REGINFO enthalt einen einzelnen BITSET, der eine (ein Teil einer) Reihe der Konfliktmatrix ist. Da keine zwei 
einfachen REGINFOs miteinander in einem Konflikt stehen konnen, besteht der untere rechte Quadrant der Matrix nur 
aus Nullen. Da die Matrix syrnmetrisch ist, ist der obere rechte Quadrant die Transposition des unteren linken. Folglich 
muB nur die linke Seite der Matrix gespeichert werden. Daher sind die Konflikt-BITSETs nur jeweils c->ri_complex-Bits 40 
anstelle von c->ri_total. 

Zur Bestimmung, ob zwei REGINFOs, A und B, mit den BITSETs in Konflikt stehen, ist es notwendig, zuerst einen 
Test zu rnachen, um zu sehen, ob sie einfach oder komplex sind (id mit c->ri_complex vergleichen). Wenn eine der bei- 
den komplex ist, das seiner ID entsprechende Bit im Konflikt-BITSET der anderen REGINFO ansehen. Wenn beide 
komplex sind, kann jedes Bit angesehen werden; sie miissen gleich sein. Wenn keine komplex ist, stehen sie nicht in ei- 45 
nem Konflikt. 

Konflikte werden aus den Lebendigkeitsinformationen berechnet, die in der IL gespeichert sind (generiert durch Com- 
puteLive). ComputeConflicts fuhn einen Einzeldurchlauf iiber den DL-Code durch, wobei der BITSET komplexer RE- 
GINFOs, die am aktuellen Punkt lebendig sind, aus den gesetzten Pseudoregistern, die an diesem Punkt lebendig sind, 
generiert wird. Wahrend jede komplexe REGINFO zum lebendigen Satz hinzugefugt wird, wird sie markiert, daB sie mit 50 
jeder REGINFO, die bereits im lebendigen Satz ist, in Konflikt stent. Beim Auffinden jeder einfachen REGINFO wird 
sie markiert, daB sie mit dem aktuellen lebendigen Satz in Konflikt steht. 

3. Sortieren der REGINFOs nach •Registerprioritat' 

55 

OC-SortRI setzt Prioritaten unter den REGINFO-Strukturen auf der Basis verschiedenster abstimmbarer Parameter. 
Die Gewichtsparameter sind zueinander relativ, daher hat eine Multiplikation aller davon mit einer Konstante keinen Ef- 
fekt. 

OC_RegAUocConflictWeight: 

Auf die Graphfarbung des Konfliktgraphen gelegtes Gewicht. Hohere Hinstellungen dieses Parameters begiinstigen Zu- 60 
ordnungen, die mehr verschiedene REGINFOs in Register geben, ungeachtet davon, wie oft diese REGINFOs tatsach- 
lich verwendet werden. Es ist zu beachten, daB REGINFOs mit weniger Verwendungen auch dazu tendieren, eine kur- 
zere Lebenszeit aufzu weisen, und daher gegeniiber REGINFOs mit langer Lebenszeit wahrscheinlich begunsUgt werden. 
OC_RegAliocDefWeight: 

Auf Definidonen gelegtes Gewicht. Hohere Werte von OC_RegAUocDefWeight begunstigen REGINFOs mit mehr ver- 65 
schiedenen Definitions-IL-Anweisungen. 
OC^RegAUocUseWeight: 

Auf Verwendungen gelegtes Gewicht. Sowohl OC_RegAllocDefWeight als auch OC_RegAUocUseWeight tendieren 
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ln^^^ebenszeil und vielen uses/defs zu begiinshgen (<^^ffl 



dazu, REGINFOs mil lanP^ebcnszeil und vielen uses/defs zu begiinshgen (c^^Rl nichl REGINFOs, die lange Zcil 
nur 'herumhangen', ohne verwendet zu werden). 
OC_RegAllocResorlRatc: 

Dieser Parameter steueri, wie viel er sortiert, uni eine gute Farbung zu erh alien. Wenn OC_Reg A ilocConflict Weight 
5 gleich 0 ist, ist dies irrelevant und solile 0 sein (= = Unendlichkeit). Kleine Zahien (> 0) bedeuten mehr aufgewendete 
Zeil und eine bessere Farbung. 

4. Regis! erwahl 

10 Die REGINFOs in einer Serie von Zwangsbedingungen. Die ersten Zwangsbedingungen sind erforderlich, so wird 
nach ihrer Anwendung, wenn keine Register iibrig sind, die REGINFO nichl einem Register zugewiesen (Ziel = -1 ). Die 
ubrigen Zwangsbedingungen sind erwiinscht, aber nicht erforderlich, so wird, wenn irgendeine gegebene Zwangsbedin- 
gung dazu fuhren wurde, daB der Satz moglicher Register leer wird, diese uhersprungen. Sobald alle Zwangsbedingun- 
gen angewendet wurden. wird das Register mit der niedrigsten Nummer aus dem Satz gewahit und dieses verwendet. 

15 TYPE [erforderlich]: 

muB ein Register wahlen, das einen Wert dieses Typs halten kann (Info von Maschinenmodell). 
INUSE [erforderlich!: 

kann kein Register wahlen, das bereits einer REGINFO zugeordnet wurde, welche in einem Konflikt steht (oder irgend 
etwas, das diese uberlappt). 
20 BASEREGS [erforderlich]: 

kann kein Register verwenden, daB der Rahmen als etwas wie frame/stack/base pointer reserviert. 
CLOBBERED: 

es wird versucht, kein Register zu verwenden, daB von jemandem wahrend der Lebenszeit der REGINFO zerstort wird. 
DEF CONSTRAINTS: 

25 es wird versucht, ein Register zu verwenden, das die DEST-Zwangsbedingungen vom Maschinenmodell fur jede EL er- 
fullt, die diese REGINFO definierl. 
USE CONSTRAINTS: 

es wird versucht, ein Register zu verwenden, das die SRC-Zwangsbedingungen vom Maschinenmodell fur jede IL er- 
fiillt, die diese REGINFO definiert. 
30 COMPATIBILITY: 

es wird versucht, ein Register zu verwenden, das mit einer anderen REGINFO in der Kompatibilkatsliste kompatibel ist, 
dem bereits ein Register zugewiesen wurde. 

Sobald alle REGINFOs Registern zugewiesen wurden (oder dies fehlgeschlagen ist), wird ein erneuter Durchlauf uber 
die REGINFOs durchgefuhrt, wobei nach uber die Kompatibilitatszwangsbedingung zu andernden Registern gesucht 
35 wird (d. h. kompatible REGINFOs, die nach dieser zugewiesen wurden, und die aus irgendeinem anderen Grand nicht in 
dasselbe Register gehen konnten). 

TRANSFORMATIONS -(OPTIMIERUNGS-)DURCHLAUFE 

40 Die Transformauonsdurchlaufe befinden sich im Kem des optimierenden Kompilierers 104. Jeder Durchlauf macht ei- 
nen Versucht, einen Teil des Codes neu zu schreiben, so daB die Bedeutung des Codes gleich bleibu der produzierte End- 
code jedoch schneller lauft. Einige der Transformationsdurchlaufe verbessern selbst nicht die Qualitat des Codes, son- 
dern ermoglichen statt dessen anderen Durchlauf en, den Code zu verbessern. So tendieren die Durchlauf e dazu, am be- 
sten in Kombinationen zu arbeiten, und sind weniger effektiv, wenn sie allein verwendet werden. Daher werden viele 

45 Durchlaufe wie Dead Code Elimination wiederholt laufen gelassen. 

Dead Code Elimination (compiler/oc_common/src/oc_usedef.c) 

Der Totcode-Eliminierungsdurchlauf (OCJhrnDeadCode) entfernt jeden Code, der tot ist, sowohl auf der Basis der 
50 DatenfluB- als auch der SteuerfluBinformationen. DatenfluBinformauonen werden verwendet, um IL_NODEs zu elimi- 
nieren, die keine Nebeneffekte haben, und deren Ergebnisse ungenutzt sind. SteuerfluBinformauonen werden zur Entfer- 
nung aller IL_NODEs verwendet, die niemals ausgefuhrt werden (unerreichbarer Code). Femer wird eine bestimmte 
neue Verzweigungszielsetzung vorgenommen. Das verwendete Verfahren wird nachstehend beschrieben. 

Diefolgenden Schritte wiederholen, bis keine Anderungen mehr gemacht werden. 

55 

1. Uber die IL_NODEs in statischer Prograrnmreihenfolge iterieren. 

a) Wenn die Instrukuon unerreichbar ist, diese entfernen. Die Insumktion ist unerreichbar, wenn sie ein LA- 
BEL ist, das nicht das Ziel irgendeiner anderen Instruktion ist, oder wenn sie ein GOTO oder CGOTO zur 
nachsten Instruktion ist, oder wenn die Instruktion direkt nach einer unbedingten Verzweigung steht und kein 

60 LABEL ist. 

b) Wenn die Instruktion keinen NebenefFekt hat, und sie keine andere Verwendung als sich selbst hat, diese 
entfernen. 

c) Wenn eine festgelegte Verzweigungsinstruktion zu einer unbedingten Verzweigung springt, die Instruktion 
neu zielrichten (z. B. ein GOTO zu einem GOTO). 

65 d) Auf eine bedingte Verzweigung zur nachsten Instruktion prufen, die von einer Verzweigung nach anderswo 

gefolgt wird (L2). In diesem Fall wird die Bedingung umgekehrt, und die bedingte Verzweigung wird neu auf 
L2 zielgerichtet. 
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Fifc. 16 veranschauticht insbe^J^e ein Beispicl einer Totcodeeliminierung und Ac^^iprtifungselinnnierung. 

(conipiler/ooci_elini_achk.c) 

Dor Durchlauf zur Adressenprufungseliminierung verwendet DaienfluBanalysetechniken, inn unnotige Adressenaus- 5 
richlungspriifungen zu eliniinieren. Der Code arbeitet iniliels der Durchfuhrung einer Wertinferenz uber eine Algebra 
von gerade und ungerade. Mil anderen Worten wird der Code analysiert, urn zu bestimmen, ob an irgendeinem gegebe- 
nen Punkl ein Pseudoregister einen geraden, ungeraden oder unbekannlen Wert enthalt. Diese Analyse wird global 
durchgellihil und arbeitet quer uber Verzweigungen. Dies bedeutet, daB sie fur Schleifen und durch andere Steuerfliisse 
urhcilcl, und besonders gut arbeitet, wenn eine einfache Aufrollung von Schleifen vorgenommen wird.4 Das verwendete 10 
Verfahren wird nachstehend beschrieben. Es ist ein iteralives Verfahren, das versucht, einen konservativen festgelegten 
Punki zu erreichen. Werte werden auf drei Hauptwegen abgeleitet. Erstens kann, wenn ein Pseudoregister einer Konstan- 
len /ugewiesen wird, der Wert, abgeleitet. werden. Zweitens kann, wenn ein Pseudoregister das Resultat einer Operation 
mil bckannten Argumenten ist, der Wert abgeleitet werden. Beispielsweise werden zwei gerade Zahlen addiert, urn eine 
weiiere gerade Zahl zu ergeben. SchlieBlich liefern bedingte Verzweigungen Informalionen uber den Wert von Pseudo- is 
regisiern. Wenn beispielsweise ein Pseudoregister auf den geraden Zustand getestel wird, wissen wir, daB es entlang ei- 
ner Vcr/weigung gerade ist, und daB es entlang der anderen Verzweigung ungerade ist. 

Die folgenden Schritte wiederholen, bis es zu keiner Anderung der uberlagerten (interferenced) Werte an irgendeiner 
Sprungmarke rnehr komint. 

20 

1 . Die Definitionsliste fur jedes Pseudoregister in infvals loschen (ein Array von INFVALs, indexien von einem 
Pseudoregister). 

2. Uber die IL_NODEs in statischer Programmreihenfolge iterieren. 

a) Wenn die Instruktion angesichts der aktuell bekannten Inferenzwerte vereinfacht werden kann, die Instruk- 
tion durch die einfachere Version ersetzen. Anderungen der Instruktion verursachen, daB die gesamte Schleife 25 
wiederholl wird. 

b) Die infvals auf der Basis der Ausfuhrung der aktucUcn Instruktion aktualisicrcn. 

i) Wenn die Instruktion bedingt ist, von der ein Wert abgeleitet werden kann, die am Ziel-LABEL und 
CGOTO gespeicherten Inferenzwerte mit dem geeigneten Inferenzwert aktualisieren. 

ii) Wenn die Instruktion unbedingt ist und ein Pseudoregister definiert, den Wert dieses Pseudoregisters 30 
in infvals aktualisieren. Der Wert ist unbekannt, auBer die Operation ist ein SET, oder ist ein Spezialfall, 
wie die Addition von zwei geraden Zahlen. 

c) Wenn die Instruktion ein LABEL ist, die infvals mit den Inferenzwerten bereits an der Sprungmarke kom- 
binieren. 

d) Wenn die Instruktion eine Verzweigung ist, die infvals mit den an der Sprungmarke der Verzweigung ge- 35 
speicherten Inferenzwerten kombinieren. Anderungen der infvals verursachen, daB die gesamte Schleife wie- 
derholt wird. 

c) Wenn die Instruktion eine bedingte Verzweigung ist, werden alle von dieser Bedingung abgeleiteten Werte 
mit infvals kombiniert. 

0 Wenn die Instruktion eine unbedingte Verzweigung ist, das infvals-Array andem, um die am nachsten LA- 40 
BEL gespeicherten Inferenzwerte zu werden. Dies wird durchgefuhrt, um die Instruktionen in ihrer statischen 
Reihenfolge zu verarbeiten, und die abgeleiteten Werte an der unbedingten Verzweigung sind nicht dieselben 
wie jene an ihrem statischen Nachfolger. 

Fig. 17 veranschaulicht insbesondere ein Beispiel der Adressenprufungseliminierung. Um die Leistung der Analyse 45 
zu vcrbessern, kann ein Pseudoregister andere Werte annehmen als einfach ODD, EVEN oder UNKNOWN. Ein Pseu- 
doregister kann auch als EQUIV ALEN T zu einem anderen Pseudoregister oder EQUIVALENT zu einer binaren Opera- 
I ion von zwei Pseudoregistern markiert werden. Dies verbessert die Qualitat der Analyse, indem ermoglicht wird, daB In- 
fomiuiionen iiber ein Pseudoregister zu anderen Pseudoregistern propagiert werden. Beispielsweise wird angenommen, 
duL> ilas Pseudoregister Rl und das Pseudoregister R2 fur Equivalent befunden werden. Wenn das Verfahren zeigen kann, 50 
daB Rl gerade ist (beispielsweise iiber ein Verzweigungstestergebnis), muB auch R2 gerade sein. 

Ks isi zu beachten, daB das Verfahren ein konservatives ist, die Werte, die abgeleitet werden, miissen monoton anstei- 
gen. Mil anderen Worten, wenn zu irgendeiner Zeit wahrend der Ausfuhrung das Verfahren bestimmt, daB ein Wert an ei- 
nem Punkt im Programm EVEN ist, muB es der Fall sein, daB der Wert wirklich EVEN ist. Das Verfahren zeigt niemals 
an, daB ein Pseudoregister wahrend einer Iteration EVEN ist, und daB es wahrend einer anderen Iteration UNKNOWN 55 
ist. Aus dieser Eigenschaft kann geradlinig die Beendigung des Verfahrens abgeleitet werden. 

I Iois ting (compiler/oc_common/src/oc_hoist.c) 

Hoisting, das allgemein als schleifenin van ante Codebewegung bezeichnet wird, ist. der ProzeB der Bewegung von Be- 60 
rechnungen, die in bezug auf eine Schleife auBerhalb dieser Schleife konstant sind. Dies sieht allgemein eine Beschleu- 
nigung vor, da der Code nur ein einziges Mai anstatt von einmal fur jede Schleifeniteration ausgefuhrt wird. 

1. IL neu numerieren (d. h. so daB die id-s in einer Reihenfolge sind). 

2. Fiir jede Ruckwartsverzweigung (d. h. eine potentielle Schleife) Dinge auszuhoisten versuchen. 65 

a) Wenn es einen weiteren Einsprungpunkt in die Schleife gibt, wird nichts aus dieser Schleife ausgehoistet. 

b) Uber die IL_NODEs innerhalb der Schleife in statischer Reihenfolge iterieren, 

i) Wenn ein Knoten die folgenden Bedingungen erfullt, kann er gehoistet werden: 
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-weWet odcr definiert kein 'echles Register'. 



(a) Er verwewlet odcr definiert kein 'echles Register'. 

(b) Er verwendei kein innerhalb der Schleife geseiztes Pseudoregisier. 

(c) Er hal keinc Nebeneffekte. 

ii) Fur irgendeine OP, die gehoisiet werden kann, jedes Pseudoregister, die sie definiert, neu benennen. 
5 iii) Den EL_NODE iiber die Schleife bewegen. 

iv) A lie IL NODEs neu nunierieren. 

v) Wenn eine Verzweigung detekliert wird, zuni Ziel der Verzweigung uberspringen (da nichl besummt 
werden kann, oh die Verzweigung ausgefuhrt wird, kann der Code nicht gehoistet werden). 

iu Der Hoisling-Diirchlauf ist fur den OOCT nicht immer eftekuv. Der Hauptgrund daftir ist, daB viele Schleifen auch 
Einsprungpunkte sind, so daB sie niehrfache Einspriinge in die Schleife aufweisen und vom IIoisting-Durchlauf nicht be- 
rucksichtigt werden. Dieses Problem konnte mittels der Durchfuhrung einer M Sprungmarkenteilung ,, behoben werden, 
wohei eine neue Sprungmarke geschaffen wird, die als Ziel fur die Schleife verwendet wird. Gehoistete Operafionen 
konnen dann zwischen die Originalsprungmarke und die neu geschaffene Sprungmarke gehoben werden. Dies wird bald 

15 implemenliert. 

Common Subexpression Elimination (CSE) (compiler/oc_common/src/oc.cse.c) 

Common Subexpression Elimination (CSE) ist eine Technik, die zur Eliminierung redundanter Berechnungen dient. 
20 Der Kompilierer 104 verwendet ein globales CSE-Verfahren. 

Das Grundverfahren wird nachstehend zusammen mit einem Erlauterungsbeispiei in Fig. 18 beschrieben. 

1 . Wahrend der Durchfuhrung von Anderungen fur jede EL_NODE, die ein Ziel aufweist (Zeile 1 im Beispiel) fol- 
gendes tun: 

25 a) Paarweise alle Verwendungen des Ziels prufen, urn zu sehen, ob eine die andere dominiert (A dominiert B, 

wenn alle Pfade zu B durch A gehen mussen). Fur jedes derartige Paar A und B (Zeile 2 und 4) folgendes tun: 

ii) Priifcn, ob A und B 'ubcrcinstimmcn' (gleicher OP-Codc und gleiche Qucllcn), wenn nicht, zum riach- 
sten Paar von Ausdriicken gehen. A und B sind ein 'allgemeiner Teilausdruck'. 

iii) Ausgehend von A und B auf folgende Weise einen groBeren allgemeinen Teilausdruck zu finden ver- 
30 suchen. Wenn A und B Ziele aufweisen, und das Ziel von B eine eindeutige Verwendung C hat (Zeile 5), 

prufen, ob das Ziel von A irgendeine Verwendung D hat (Zeile 3), so daB D C dominiert, und D nut C 
ubereinstimrnt. Wenn dies der Fall ist, D und C zum allgemeinen Teilausdruck hinzufugen, und einen gro- 
Beren Teilausdruck mit A=D ? B=C zu finden versuchen. 

(iv) Da nun zwei allgemeine Klainmerausdrucke A (Zeilen 2, 3) und B (Zeilen 4, 5) vorliegen, muB der 
35 Code neu geschrieben werden, so daB die Verwendungen von B nun start dessen A verwenden. Wenn das 

Ziel von A vor der Verwendung durch B geandert werden konnte, wird eine Kopie in ein neues Pseudo- 
register verwendet. 
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Fig. 18 veranschaulicht insbesondere ein Beispiel der Common Subexpression Elimination (CSE). 

Copy Propagation (compiler/oc_common/src/oc_copyprop.c) 



Copy Propagation ist eine Transformation, die versucht, Verwendungen des Ziels einer Zuweisung durch die Quelle 
der Zuweisung zu ersetzen. Wahrend Copy Propagation selbst nicht die Qualitat des Codes verbessert, wird haufig ein 
45 Code produziert, wo das Ergebnis einer Zuweisung nicht langer verwendet wird, und so kann die Zuweisung eliminiert 
werden. Das Copy Propagauon-Verfahren wird nachstehend beschrieben. 

1. Fur jede ASSIGN-Operation. 

a) Wenn die Quelle von ASSIGN eine einzige Definition aufweist, und die einzige Verwendung dieser Defini- 
50 tion ASSIGN ist, und das Ziel von ASSIGN zwischen der Definition und ASSIGN weder modifiziert noch ver- 
wendet wird, dann die Definition in eine Definition fur das Ziel von ASSIGN modifizieren und ASSIGN ent- 
femen. 

b) Fur jede Verwendung des Ziels von ASSIGN testen, ob ASSIGN die einzige Definition dieser Verwendung 
ist, und testen, ob die ASSIGN-Quelle zwischen ASSIGN und der Verwendung sowohl lebendig als auch gul- 

55 tig ist. Wenn beide Tests wahr sind, die Verwendung des Ziels durch eine Verwendung der Quelle ersetzen. 

Fig. 19 veranschaulicht insbesondere ein Beispiel einer Copy Propagation. Fig. 20 veranschaubcht insbesondere ein 
Beispiel einer Constant Folding. 

60 Constant Folding (compiler/oc_common/src/oc_cfold.c) 

Constant Folding ist eine Transformation, die Operationen an konstanten Werten zur Kompilierzeit untersucht. Wenn 
die IL zwei Konstanten miteinander addiert, ersetzt Constant Folding beispielsweise diese IL-Instruktionen durch eine 
einzige SET-Instruktion, die das Ziel der Addition der Summe der beiden Konstanten zu weist. 
65 Das Verfahren fur den Constant Folding-Durchlauf ist sehr geradlinig. Jede IL-Instruktion wird der Reihe nach unter- 
sucht. Fur jede arithmetische und logische Operation (ADD, SUB, BAND, BOR etc.) wird, wenn alle ihre Argumente 
Konstanten sind, die EL-Operation durch eine SET-Operation ersetzt, die das Ziel im Pseudoregister auf den Wert der 
Operation an den konstanten Argumenten setzt 
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Der Kompiliercr 104 hal auch einen Musterubereinstimmungs- bzw. engL Pattern Matching-Optimierungsdurchlauf, 
der bekannle Muslcr von EL-Inslruklionen durch effizientere Versionen ersetzt . Es gibt derzeit keine Musler, die allge- 
mein mil voin OOCT generierien IL-Muslern ubereinstimnien, so daR der Pattern Matching-Durchlauf nicht durchge- 5 
fuhrt wird. 



Nachdem die IL generiert wurde, und die Transformationen durchgefuhrt wurden, urn die QualiLSi des Codes zu ver- to 
bessern, werden drei Kompilierer-104-IIauptdurchlaufe verwendet, um den Code zu generieren. Bis zu diesem Punkt 
waren die IL und die Trans format ionsdurchlaufe maschinenunabhangig, diese drei Durchlaufe sind jedoch stark von der 
Zielarchitekrur ahhangig. 



Die OOCT-IL ist eine RISC-ahnliche Architektur, die ohne Modification nicht effizient auf die Zielarchitektur abge- 
bildet wird. Insbesondere ware es suboptimal, eine Zielinstrukuon fur jede IL-Instruktion zu emittieren. Da die Zielar- 
chitektur eine CISC-Architektur ist, konnen oft mehrfache IL-Instruktionen zu einer einzigen Zielinstruktion kombiniert 
werden. Der Instruklionsfaltungs- bzw. engl. Instruction Folding-Durchlauf ist ausgebildet, um dieses Problem zu losen, 20 
indem Gruppen von IL-Instruktionen markiert werden, die zu einer einzigen Zielinstruktion kombiniert werden konnen. 

Der Instruction Folding-Durchlauf arbeitet, indem nach einer von einer Anzahl verschiedener vordefinierte Instrukti- 
onskombinationen gesucht wird. Die folgenden Kombinationen werden verwendet: 

- Konstanten werden in verschiedene Operationen gefaltet, wie ADD, SUB etc. 25 

- SETCC-Instruktionen werden in die Instruklion gefaltet, auf deren Basis sie die Bedingungscodes setzen. 

- DIV-, REM-Paarc mit dcnsclbcn Argumcntcn werden zusammcn gefaltet. 

- ADD-, SUB- und ASL-Operationen konnen in eine einzige 'lea-Operation oder in die Adressenberechnung von 
LOAD oder STORE gefaltet werden. 

- 16 Bit-BSWAP-, STORE-Kombinationen werden in zwei getrennte 8 Bit-Speicherungen gefaltet. 30 

- LOAD-Operationen werden in verschiedene Operationen gefaltet, wenn ihr Ergebnis als zweites Argument ver- 



Der Instruction Folding-Durchlauf entscheidet einfach, wenn Instrukrionen gefaltet werden sollten, er fuhrt die tat- 
sachliche Faltung nicht aus, die dem Maschinencode-Generierungsdurchlauf uberlassen wird. Der Instruction Folding- 35 
Durchlauf markiert zu faltende Instruktionen auf zwei Wegen. Erstens kann jeder Operand eines Knotens mit einem 
"fokT-Bit markien werden. Zweitens werden Instruktionen, von denen alle Verwendungen in eine andere Instruktion ge- 
faltet sind, mit einer IL_COMBINE-Flagge und mit dem mmFold-Feld markiert, das Informationen uber den Weg liefert, 
auf dem die Instruktion gefaltet wird. Der Registerzuordner und die Maschinencodegenerierung verwenden diese Felder, 
um korrekt zu arbeiten. 40 



Sobald der Registerzuordner (RegAlloc) Register fur alle REGINFOs gewahlt hat, die er wahlen kann, ist es notwen- 
dig, den Code durchzugehen und ihn zu modifizieren, um diese physischen Register anstelle der Pseudoregister zu ver- 45 
wenden. Femer ist es notwendig, einige zusatzliche Pseudoregister temporar in reale Register zu geben, so daB der As- 
semblierer den Code fur diese Instruktionen generieren kann. Dies wird im allgemeinen das Einfugen eines Leer- und 
Fullcodes erfordem, um die Werte zu speichern und wiederherzustellen, die der RegAlloc in diese Register plaziert hat. 
Um dies durchzufuhren, verwendet OC_RegUseAlloc einen Zwangszuordner (GetReg) und fiigt Leer- und FUUzeichen 
ein, um Register emeut zu verwenden. 50 

OC_RegUseAlloc fuhrt einen einzelnen Durchlauf iiber den Code durch, wobei der Zustand der physischen Register 
in einem 'st at'- Array modifiziert und verfolgt wird. Das stat- Array zeichnet auf, was in jedem Register zu einem gegebe- 
nen Moment ist (oder sein sollte), und ob der Wert im Register oder die Leerstelle (oder beide) korrekt ist. OC RegUse- 
Alloc arbeitet als Serie von Stufen, von denen jede spezifische Modifikationen an den aktuell verarbeiteten Instruktionen 
vomimmt. Wenn mehrfache IL-Instruktion durch den Instruction Folding-Durchlauf zusammen gefaltet wurden, werden 55 
sie als einzige Instruktion behandelt. Die Stufen sind wie folgt: 

1. Wenn die Instruktion irgendein physisches Register direkt verwendet, sicherstellen, da£ jegliche Fullzeichen in 
diesen Registem nach dieser Verwendung auftreten. Die Instruktion modifizieren, um Register zu verwenden, die 
den Pseudoregistem durch die Reg Alloc- Analyse zugeordnet wurden. Alle Register verriegeln, so daB sie nicht. er- 60 
neut verwendet werden. 

2. Die Instruktion modifizieren, um Register zu verwenden, die durch GetReg- Aufrufe der vorhergehenden In- 
struktion temporaren zugeordnet wurden. Alle diese Register verriegeln. 

3. Die Statusinformationen im stat- Array saubem, um alle Register zu reflektieren, welche die Instruktion zerstort, 
wobei Leerzeichen nach Bedarf eingefugt werden. Das Zielregister in das Register andern, das vorn RegAlloc zu- 65 
geordnet wurde, sofern dies geschehen ist (es ist zu beachten, daB es nicht notwendig ist, dieses Register zu verrie- 
geln, da es verwendet werden kann, um ein sre zu halten, wenn notwendig). 

4. Den Code modifizieren, um Quellen in das Register zu geben, wo dies fur die Zielcodegenerierung notwendig 
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INSTRUCTION FOLDING (compiler/oc_common/src/ix86_ifold.c) 
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isl. Dies involvien emiK\ufrul* von GelReg fur jcnc Qucllenoperandcn, c^JP^egislem sein niusscn. 

5. Alle Regisier, die verriegelt wurden, freigeben. 

6. Zielc festlegen, um reale Regisier zu verwenden, wo dies fur den Zielcode nolwendig isl. Dies in vol vierl einen 
Aufruf von GelReg. 

5 7. Das stal -Array finalisieren, um das Ergebnis dieser Operation zu refleklieren, und alle verwendet en Regisier fest- 

legen, wobei ihre 'bcfore'-Stelien in die nachsle Instruktion gesetzt werden (so daB jegliche Leer/Fullzeichen nach 
dieser vollendeten Insiruktion plazierl werden). 

lis isl wichlig, daB stal- Array zu verstehen. Hs isl ein Array von Datenstrukturen, die von eineni physischen Register 
id (alle Register unier MM_NuniRegs sind physische Regisier) indexiert werden. das den Status eines gegebenen physi- 
schen Registers anzeigt. Die Struktur enthalt die folgenden Feider: 

1 . ri: Die REGTNFO-Struklur, die das Pseudoregister identifiziert, das aktuell riiit. diesem realen Register assoziiert 
isl (kann 0 sein, uni keine Assoziation anzuzeigen). Dies kann entweder ein Pseudoregister, das diesem Register 
15 voni RegAlloc zugeordnet wurde, oder ein von GetReg temporar zugewiesenes sein. 

2 alt_ri: Eine REGINFO-Struktur, die ein zusatzliches Pseudoregister identifiziert, das auch in diesem Regisier isl. 
Dies wird verwendet, wenn GetReg ein Pseudoregister eineni physischen Register zuweist, wahrend der RegAlloc 
cin anderes hierher (in ri) gegeben hat. 

3. flags: Flaggen zum Identifizieren des Zustands des Registers. Reg Valid wird beispielsweise verwendet, um an- 
20 zuzcigen, daB der Wert im Register gultig ist. Wenn Reg Valid nicht gesetzt ist, rnuB das Register gefiillt werden, be- 

vor es verwendet werden kann. Fur eine vollstandige Beschreibung der moglichen Raggen siehe ix86_regalloc. 

4. before: Die Instruktion, wo Leer- oder Fullzeichen fur dieses Register plaziert werden sollten. 

25 MASCHINENCODEGENERIERUNG 

Der Maschincncodc fiir das Zicl wird in zwei Durchlaufcn gencricrt. Der crstc Durchlauf wird zur Bcstimmung der 
CiroBc iter Instruktionen verwendet, so daB Verzweigungsdistanzen berechnet werden konnen. Der zweite Durchlauf 
nimtiii die tatsachliche Codegenerierung vor. Die beiden Durchlaufe sind identisch, auBer daB der ersie den Code in einen 
.«) Arbeiispuffer generiert, und nicht die korrekten Verzweigungsdistanzen aufweist, so daB nahezu der gesamte Code ge- 
mcinsam genutzt wird. 

Heiile Durchlaufe bestehen aus einem Einzeldurchlauf durch die IL-Instruktionen der Reihe nach. Fur jede Instruktion 
wird eine durch den OP-Code und Typ indexierte Tabelle verwendet, um eine Funktion zur Generierung des Codes wie- 
ilcrauf/.ufinden, Diese Codegenerierungsfunktionen verwenden EMTT-Makros, die ein generalisiertes Verfahren zur Ge- 
ns n eric rung von Zielinstruktionen sind, ohne daB die genaueren Details des Ziels bekannt sein muss en (siehe 
i \So Asni_Emit. [h 7 c]). Diese Makros vereinfachen die Assemblierung von Instruktionen, die irgendeinen der Zieladres- 
sicrungsniodi verwenden. 



40 



SEGMENTVERWALTUNG 



Der vom CX)CT kompilierte Code wird innerhalb einer SEGMENT-Datenstruktur gespeichert. Es gibt zahlreiche 
wichiige Themen, die mit der Verwaltung von Segmenten assoziiert sind. Erstens haben Segmente einen speziellen Spei- 
chcr/.uordner, um die Segmentspeicherung zu behandeln. Zweitens wird diskutiert, wie Segmente geschaffen und in das 
System installiert werden. Drittens wird diskutiert, wie Segmente geloscht werden (wenn diese Option eingeschaltet ist). 
45 SchlieBlich wird die Segmentverriegelung diskutiert, wenn die Segmendoschung ein ist. 

SEGMENT ALLOCATOR (compiler/S eg Alloc. [h,c]) 

Die Spcicherverwaltung fur Segmente im OOCT wird mit einem speziellen Zuordner bearbeitet. Zur Zeit der OOCT- 
50 Initiuiisicrung wird der Segmentzuordner bzw. engl. Segment Allocator (SegAlloc) mit einem groBen Speicherstiick in- 
iiialisierL Dann sieht die SegAlloc-Einheit die Fahigkeit vor, ein ungenutztes Speicherstuck mit variabler GroBe (wie 
malloc) anzufordern, um ein vorher zugeordnetes Speicherstuck frei zu machen (wie free), und eine Statistik liber die ak- 
tuelle Speicherverwendung anzufordern. 

Der SegAlloc ist komplexer als der ZONE-Zuordner, da er eine variable GroBenzuordnung behandeln muB. Der Se- 
55 gAlloc verwendet ein ziemlich standardmaBiges Zuordnungsverfahren. Der Zuordner halt eine sortierte freie Liste von 
Stucken und verwendet einen 32 Bit-Anfangsblock fur zugeordnete Blocke, um ihre GroBe anzuzeigen. Um ein Spei- 
cherstuck zuzuordnen, wird die freie Liste nach einem Stuck durchsucht, das zur angeforderten GroBe paBt. Wenn der 
Rest des S tiicks groBer ist als eine MindestgroBe, wird er geteilt, und der Rest wird zur frei en liste hinzugefugt. Umein 
Stuck frei zu machen, wird es zur freien Liste hinzugefugt Da die Geschwindigkeit des Freimachens von Speicher kein 
60 kritischer Faktor ist, wird die freie Liste nach benachbarten freien Blocken durchsucht, die zu einem einzelnen freien 
Block kombiniert werden. 

SEGMEOTSCHAFFUNG UND -INSTALLATION (compiler/ooct_lrace.c, compiler/SegMgr. [h,c],) 

65 Nachdem die Hauptstufen der Kompilierung vollendet sind, ist das Endergebnis ein Speicherblock, der den verschieb- 
lichen Zielcode enthalt. Der nachste Schritt ist die Schaff ung eines Segments fur diesen Code, und die Installation dieses 
Segments in den fur Segmente zugeordneten Raum. OOCT_Install nimmt diese Funktion vor. Anfanghch wirdPlatz fur 
das Segment in der ZONE-Speicherregion zugeordnet. Das Segment wird mit einer Liste der Basisblocke, die vom 
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Blockwahler 114 gewahll werder^^^aB die Segntcnte spater gesucht werden konnen^^Berauszufinden, ob sic eine 
gegebene Origin alinstruki ion enttSn^i), unci mil dem gencricrten Code initialisiert. Eir^ffufruf von SEGMGR. Install 
mac hi das Segment zu einem kontinuierlichcn Speichcrblock und kopiert diesen in den Raum, der unter \ferwendung der 
SegAlloc-Einheit fur Segmente zugeordnel wurde. 

Nachdem das Segment geschaflen und in den Segmentzunrdnungsraum bewegt wurde, muB die Uhersetzungslabelle, 5 
die anzeigl, welche Originalinstruktionen fur sie kompilierten Code haben, aktualisiert werden. Fur jede der Originalin- 
1 struktionen, die externe Eintrage sind, wird die Ubersetzungslabelle roil der korrekten Adresse im fur diesen Eintrag ge- 

ncricrten Code aktualisiert. Ferner wird die Ubersetzungstabelic mil der TRANS_ENTRY_FLA G markiert, um anzuzei- 
iien, daB die K-lnslruktion einen gulligen Hintrag hat. 

... 10 

SEG MENTLOSCI RING (compiler/ooct_trace.c, compiler/SegDel.fh,c]) 

Wenn der Kompilierer 104 einen Eintrag in die Ubersetzungslabelle schreibt, kann er einen alten uberschreiben, der 
sich ncreits darin befand. Kein Interpretierer 110 wird den alten Eintrag lesen und zum alten Segment springen konnen. 
W enn ein Segment keine Eintrage in der Ubersetzungslabelle aufweist, und es keinen Interpretierer 110 gibt, der das Seg- 15 
mcni verwendet, kann es geloscht werden, und sein Speicher kann fur ein anderes Segment verwendet werden. Dieser 
Ahschnin beschreibt, wie der Kompilierer 104 detektiert, daB ein Segment geloscht werden kann, und dieses dann loscht. 
I >er Kommunikationsabschnitt beschreibt auch detailliert die Segment verriegelung und die Segmentloschung. 

Wenn der Kompilierer 104 einen Einsprungpunkt in der Ubersetzungstabelle uberschreibt, stellt er den alten Ein- 
sprungpunkt auf eine Loschliste. Nach der Installation eines neuen Segments ruft der Kompilierer 104 SEGGEL_TryDe- 20 
sleiions auf. Diese Prozedur priift jeden Eintrag auf der Loschliste. Wenn kein Interpretierer einen Einsprungpunkt ver- 
wetnlet, wird er geloschL so daB er spater emeut verwendet werden kann. 

lodes Segment hat darin einen Einsprungpunktzahler. Wenn ein Einsprungpunkt geloscht wird, verringert der Kompi- 
lierer 104 den Einsprungpunktzahler um das Segment, das ihn enthalt. Wenn der Einsprungpunktzahler eines Segments 0 
erreiehl, verwendet kein Interpretierer 110 das Segment, und kein neuer Interpretierer 110 kann in dieses springen. Der 25 
Kompilierer 104 loscht das Segment und niachl seinen Speicher fur eine Verwendung durch andere Segmente frei. 

SEGMENTVERRIEGELUNG 

Jeder Einsprungpunkt in ein Segment hat einen Zahler, der als Verriegelung fur den Einsprungpunkt arbeitet. Der Zah- 30 
ler /.eichnet die Anzahl von Interpretierem 101 auf, die den Einsprungpunkt verwenden. Wenn der Zahler groBer als Null 
ist. werden der Einsprungpunkt und sein Segment verriegelt, und der Kompilierer 104 loscht diese nicht. Das wichtigste 
Merkmal der Einsprungpunktverriegelung ist, daB die Instruktionen, die das Segment verriegeln und entriegeln, nicht 
l eil lies Segments selbst sind. Dadurch wird es dem Interpretierer 110 ermoglicht, beliebige Instruktionen im Segment 
iiiis/.ufuhrcn, auBer es halt die Verriegelung. Die Dokumentation fur den Kompilierer 104 und Interpretierer 110 erlautert 35 
detail liert den Segment verriegeiungsmechanismus. 

ANDERE THEMEN 

lis gibt /.ahLreiche andere Themen belreffend den Kompilierer 104, die nicht gut in andere Abschnitte passen, jedoch 40 
wichrig zu verstehen sind. 

STACK WARPING (common/ooct_warp.[c,h]) 

Der Kompilierer 104 wird anfanglich einem kleinen Stapel zugeordnet, der nicht dynamisch expandiert. Da der Kom- 45 
piliercr 104 zahlreichc rekursive Prozeduren verwendet, ist leider oft die GroBe des Stapels, den er benotigt, groBer als 
die vorgesehene. Bei auf CiranPower laufenden Programmen wurden Situationen beobachtet, in denen Seitenfehler vom 
Kompilierer 104 aufgrund eines Slapeluberlaufs nicht behoben werden konnten. Anstatt zu versuchen, Abschnitte des 
Kompilierers 104 ncu zu schrciben, oder zu bestimmen, wie Seitenfehler aufgrund eines Stapeluberlaufs korrekt zu be- 
handcln sind, wird ein viel groBcrer Stapel verwendet als jener, der vom OOCT_buffer zugeordnet wurde. Die GroBe die- 50 
ses Stapels wurde so gcwahll, daB die StapelgroBe niemals ein einschrankender Faktor sein wurde (andere Faktoren, wie 
die ZONE-GroBe, sind cine groBcre Einschrankung). Um diesen Stapel zu verwenden, wurde eine saubere Schnittstelle 
ausgcbildel, OOCT Warp Stack, die es ennoglicht, daB eine Funktion unter Verwendung des groBen Stapelraums des 
OOCT aufgerufen wird. Beim Rucksprung von OOCT_Warp_Stack bleibt der Stapelzeiger unverandert. Wenn in den 
Kompilierer 104 uber ooct_Compile_Seed eingesprungen wird, dem Haupteinsprungpunkt, um einen Startparameter zu 55 
kompilieren, wird er daher unter Verwendung von OOCT_Warp_Stack aufgerufen. 

ASS ERTIONEN (common/assert. [c,h]) 

Der Code im Kompilierer 104 hat. eine groBe Anzahl von Assertionsanweisungen. Assertionen werden im gesamten 60 
Kompilierer 104 verwendet, um Konsistenzeinschrankungen zu prufen, und fur andere Fehlerzustande. Assertionen 
spielen zwei wichtige Rollcn. In der Diagnoseumgebung verursacht ein Assertionsausfall, daB das Programm anhalt, 
wahrend zur Verfolgung des Problems nutzliche Informationen angezeigt oder gespeichert werden. In der Produkdons- 
umgebung werden Assertionen verwendet, um Fehlerzustande einzufangen, und fur einen sicheren Ausgang aus der 
Kompilierung, wenn diese Zustande auftreten. Wenn der Kompilierer 104 beispielsweise Uber keinen Speicher mehr ver- 65 
, fiigt, verursacht eine Assertion, daB der Kompilierer 104 die Kompilierung dieses Startparameters abbricht. 
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SERVICEROUTINE (common/service. hl|^ 

Die Servicecinheit sichl Dienslc vor, welche in Standard-C-Bibliotheken typischerweise vorgesehen werden, wie 
printf und menisci, die voni KOI-Monitor nicht vorgesehen werden. Diese Einheit soli die Noiwendigkeit wegabstrahie- 
5 ren, diese Syslcmaufrufe im Windows- und Firmware-Aufbau anders zu behandeln. Es gibl zwei grundlegende Imple- 
mentationen dieser Servicerou linen, eine fur das Wintesl-Projekt und die andere fur den Firmware-Aufbau. 

VEI. WINDOWS-TESTUMGEBUNG 

lo Die Windows-Testunigebung spieli eine wesentliche Roile bei der raschen Entwicklung und den Tests des OOCT-Sy- 
stems. Durch die Entwicklung unter Windows werden Standard-Diagnosewerkzeuge unter MSVC vorgesehen. Terner 
sind nutzliche Werkzeuge wie Profilierer verfugbar. Zu Testzwecken wurden spezielle Testverfahren unter Windows ent- 
wickelL, welche die Testgeschwindigkeit und den Testumfang erweitert hahen. 

Zuerst wird die simuiierte Granpower-Umgebung beschrieben. Dann wird die Vergleichseinheit diskutiert, welche die 
15 meisten der fortgeschrittenen Tesltechniken vomimmt. 

SchlieBlich werden Codeauszuge des Kompilierers 104 beschrieben. 

SIMULIERTE GRANPOWER-UMGEBUNG 

20 Zur Durchfuhrung der anfanglichen Tests des OOCT sowie der fortgeschritteneren Tests und der Leistungsanalyse war 
ein Interpretierer notwendig, der unter Windows laufen wurde. Der Interpretierer 110 selbst erforderte keine Mddifika- 
tionen, aber Initialisierungsaufrufe und AOI-Systemaufrufe, die auf dem GranPower- System zur Verfugung stehen, 
muBten geschrieben werden. Ferner war, damit der OOCT unter Windows lauft, eine Ausbildung notwendig, um mehr- 
fache "Aufgaben" laufen zu lassen, da der Kompilierer 104 als gelrennte Aufgabe vom Interpretierer 110 lauft. 

25 

INTTIALISrERUNG 

Der erste Teil der Schaffung einer simulierten Umgebung unter Windows war die Schaffung eines Codes zur korrekten 
Initialisierung von KOI-Datenstrukturen und zur Simulation der KOI-Initialisierungs-API fur die OOCT-Aufgabe. Der 

30 Interpretierer 110 erwartet, daB eine Anzahl von Datenstrukturen geeignet initiabsiert wird, um irgendeinen Code.auszu- 
fuhren. Femer steuem bestirnrnte Datenstrukturelemente, ob der OOCT verwendet wird. Indem unser Initialisierung- 
scode auf dem Firmware-InitialisierungsprozeB basiert, Simulation der korrekten Initialisierung, um den Interpretierer 
110 laufen zu lassen, und einen Teil seines Grundverhaltens zu steuern. Ahnlich wurde grundsatzlich eingerichtet, daB 
die KOI-Initialisierungs-API fur die OOCT- Aufgabe auf dem von der Firmware verwendeten Code lauft. Dadurch wurde 

35 ermoglicht, daB das anfangliche Schreiben und Testen von Schnittstellen zwischen dem Interpretierer 110 (wie Aufrufe 
von OOCT_Init) unter Standard-Windows-Diagnoseumgebungen arbeitet. Es wurde auch geradlinig, die Schnittstelle zu 
andem und zu testen. 

AOI-SYSTEMAUFRUFE (wintest/MiscStubs.c, wintest/MsgStubs.c) 

40 

Der Interpretierer 110 erwartet, in einer Umgebung zu laufen, in der alle AOI-Systemaufrufe verfugbar sind. Um eine 
ausfuhrbare Anweisung auch nur zu kompilieren und zu verbinden, miissen Fragmente fiir die AOI-Systemaufrufe ge- 
schaffen werden. Viele der System aufrufe haben keine Signifikanz, wenn das System unter Windows getestet wird, und 
so werden diese Aufrufe einfach als Leerfunktionen belassen (nur da fiir Verbindungszwecke). Implernentationen der 
45 AOI-Systemaufrufe werden zur Zeitsteuerung (ScGtmSet, ScGtmRef) und fur messsgAlc, ScMsgSnd, ScMsgRcv ver- 
wendet 

Der OOCT ist stark von den Systemaufrufen zur Nachrichtenweiterleitung fur die InterprozeBkommunikation zwi- 
schen den Ausfuhrungen und dem Kompilierer 104 abhangig. Unter Windows wird eine Scheinversion dieser AOI-Sy- 
stemaufrufe verwendet, um zu ermoglichen, daB Anknupfungen innerhalb derselben Aufgabe kommunizieren (siehe 
50 oben). Die Windows- Version der Nachrichtensystemaufrufe implementiert die vollstandige Spezifikation der Systemauf- 
rufe unter Verwendung von Verriegelungen und Nachrichtenwarteschlangen. 

GETRENNTE ANKNUPFUNGEN (THREADS) FUR OMPEJERER/AUSFUHRUNGEN 

55 Um die Implementation und Diagnose unter Windows zu vereinfachen, wurden getrennte Anknupfungen fiir den 
Kompilierer 104 und den Interpretierer 110 anstelle von getrennten Prozessen verwendet. Die Verwendung von Anknup- 
fungen vereinfacht die Nachrichtenweiterleitungsimplementauon zwischen den beiden 'Aufgaben*. Femer wird die Dia- 
gnose leichter, da sowohl ein einzelnes Diagnoseprogramm fiir beide Aufgaben (Interpretierer 110 und Kompilierer 104) 
verwendet werden kann, als auch das Diagnoseprogramm ausgebildet ist, auf mehrfachen Anknupfungen zu arbeiten 

60 (uns ist kein Diagnoseprogramm bekannt, das Werkzeuge fur eine Diagnose mehrfacher Prozesse aufweist). 

VERGLEICHSEINHEIT 

Der OOCT verwendet ein einzigartiges Testverfahren, das sich als auBerst wertvoll erwiesen hat. Da der OOCT kom- 
65 pilierte Code-Ergebnisse produzieren sollte, die genau gieich sind wie jene des Interprederers 110, wurde ein Weg ge- 
schaffen, diese Ergebnisse direkt zu vergleichen. Unter der Windows-Testumgebung wurde eine Fahigkeit eingebaut, so- 
wohl unter dem OOCT als auch dem Interpretierer 110 Programme laufen zu lassen, und automatisch Zwischenergeb- 
nisse zu vergleichen. Diese Vergieiche konnen willkurlich fein abgestuft werden, bis zu Prufungen nach jeder Instruk- 
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tion. Zusamnicn mil der FahigkeiHK Verhallen von Programmen zu verglcichcn, wurde^ro aulomatischer Teslgenera- 
tor geschricben. Dcr Tesigeneralor schaffl einen 'zufailigen' Code, der dann laufen gelassen und verglichen wird. Diese 
auioni arise he Testgenerierung und dieser Vergleich schen einc auGersl umfangreiche Programmfoige vor, um zu verifi- 
zieren, daB der OOCT korrckt arbeitel. Ferner wurde ein auBerst wertvoller Weg zur Lokalisation auftretender Storungen 
vorgesehen, da dcr auloinatische Vergleich anf den Platz zeigl, wo sich der kompilierte Code und der Inlerpreiierer 110 5 
erstmals un terse hei den. 

Dieser Abschnill beschreibt die Vergleichseinheil in zwei Stufen. Zuerst wird die Infrastruktur beschrieben, die zum 
Vergleichen der Ergebnisse des kompilierten Codes mil jenen des Interpretierers 110 verwendet wird. Als zweiles wird 
die Generierung des Zufallscodes beini Testen beschrieben. 

10 

VERGLEICI ISINFRASTRUKTXJR 

Die Vergleichsinfrastruktur basiert auf der Tdee, zwei Versionen desselben K-Programms laufen zu lassen, wo der Ma- 
schinenzustand der simulierten K-Maschine (Register und Speicher) zu spezifischen Zeiten gezielt gepruft wird. Die Er- 
gebnisse dieser Priifpunkte werden dann verglichen, um zu bestimmen, ob die kompilierte Version und interpretierte Ver- 15 
sion dieselben Ergebnisse liefern. 

Fig. 21 veranschauiicht insbesondere ein Beispiel des obigen Prozesses, der eine Vergleichsinfrastruktur gemaB einer 
AusfOhrungsform der vorliegenden Erfindung aufweist. In der Praxis wird der Vergleichstest als zwei Window s-Prozesse 
laufen gelassen. Der StamrnprozeB lauft auf dem vollstandigen OOCT-Syslem mit einer Verzweigungsprotokollierung 
und Kompilierung. Der NebenprozeB lauft nur als interpretierte Version von KOI. Beide Prozesse schreiben ihre Priif- 20 
punktprotokolle in den Speicher (der NebenprozeB schreibt in den gemeinsam genutzten Speicher), um ihren Effekt auf 
den simulierten K-Maschinenzustand aufzuzeichnen. Das Stammverfahren vergleicht die Daten in den Protokollen und 
berichtet iiber Diskrepanzen. 

CODEGENERTERUNG 25 

Die Generierung des Zufallscodes fur die Vcrglcichstcsts wird von drci Einhcitcn durchgcfUhrt. Zucrst sicht dor K-As- 
semblierer einen Mechanismus zur Produktion des K-Maschinencodes unter Verwendung von C-Funkuonsaufriifeh vor. 
Als zweites werden Einheiten zur Schaffung verschiedener Arten von Basisblocken von K-OP-Codes vorgesehen. 
SchlieBlich ermoglicht die ZufalissteuerfiuBeinheit die Generierung eines Codes mit vielen verschiedenen SteuerfluBty- 30 
pen. 

K- Assembler (wintest/OOCT_Assemble. [h,c]) 

Der K-Assernblierer sieht einen geradlinigen Mechanismus zur Generierung des K-Codes aus dem Inneren eines C- 35 
Programms vor. Jeder K-OP-Code hat eine Funktion, die zur Assemblierung von Instruktionen spezifisch fiir diesen OP- 
Code verwendet wird. Die individuellen Instruktionen nehmen als Argumente einen Zeiger zum Speicher, wo der Code 
zu speichern ist, einen (moglicherweise leeren) Sprungmarkennamen, und ein Argument fiir jedes in der Instruktion ver- 
wendete Feld. Die Funktion kombiniert einfach die Felder in ihre korrekten Platze und schreibt den Code in den Puffer. 
Da Verzweigungen zu einer Sprungmarke vor der Definition der Sprungmarke eintreten konnen, wird ein zweiter Durch- 40 
lauf uber den Code verwendet, um das Verzweigungsziel zu losen. 

Einheiten zur Schaffung des Zufalls-K-OP-Codes (wintest/GenArith.c, wintest/GenCassist.c, Wintest/GenMisc.C) 

Zum Testen verschiedener TVpen von Instruktionen wurden individuelle Einheiten geschafFen, welche Basisblocke 45 
(geradliniger Code) generieren, die diese 1VP en von Instruktionen enthalten. Insbesondere werden Einheiten geschafFen, 
welche die arithmetischen und Verschiebungsoperationen, die C assist-Instruktionen und alle anderen vom OOCT imple- 
mentierten Instruktionen generieren. Die Hauptschnitlstelle zu den Einheiten erfolgt durch eine FillBasicB lock-Routine. 
Diese Routine nimmt als Argumente einen Speicherpuffer und eine Anzahl von Instruktionen, und schreibt die gegebene 
Anzahl von Instruktionen (zufallig gewahlt) in den Puffer. Die FillBasicBlock-Routine wahlt zufaUig aus einem Array 50 
von Instruktionen generierenden Funktionen, um Instruktionen hinzuzufugen. Die Einheiten enthalten eine Instruktionen 
generierende Funktion fur jeden K-OP-Code, der generien werden kann. Diese Instruktionen generierende Funktion 
wahlt geeignete Zufallswerte fur die Argumente an den Assemblierer und assembliert die Instruktionen. Instruktionen 
werden nicht vollig zufallig generiert. Statt dessen werden sie mit bestimmten Einschrankungen generiert. Wenn bei- 
spielsweise ein Register zufallig als Ziel gewahlfwird, werden niemals die Basisregister verwendet. Der Code ist auch 55 
auf die Verwendung einer Anzahl vordefinierter Speicherstellen beschrankt. In unseren Tests haben sich diese Beschran- 
kungen nicht als sehr significant erwiesen. Wenn sie sich in der Zukunft als signifikant erweisen, ist es mOglich, einige 
der Einschrankungen unter Verwendung eines komplexeren Prozesses zu reduzieren. 

Die Verwendung von Zufallstests ist wichtig, da Testinteraktionen zwischen vielen verschiedenen Instruktionen gele- 
stet. werden, was fur einen Kompilierer 104 wie den OOCT besonders wichtig ist. Tm OOCT kann sich der durch das 60 
Kompiueren einer Instruktion produzierte Code in Abhangigkeit von umgebenden Instruktionen wesentlich unterschei- 
den. 

Fig. 22 veranschauiicht insbesondere ein Beispiel der Codegenerierung fur dieselbe Instruktion mit verschiedenen 
umgebenden Instruktionen. Femer testen Zufallstests viele Falle, die Programmierer nicht testen wurden. 

Dis Einheiten zur Schaffung von ZufaUs-K-OP-Codes sind an sich fur besummte Testtypen efifektiv. Bei der Imple- 65 
mentation eines neuen OP-Codes hat es sich beispielsweise als sehr effektives Verfahren erwiesen, eine einfache Schleife 
zu schaffen, die einen Basisblock von Instruktionen unter Verwendung dieses OP-Codes ausfuhrt. Wahrend die indivi- 
duellen Einheiten effektiv sein konnen, ist zum vollstandigen Testen bestimrnter Aspekte des Kompilierers 104 ein kom- 
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Die Einheii zur SchaiYung cines Zufallssieuerflusses (wintest/Gdom control flow creation unii (GenControl)) wird zur 
Schaflfung von Tests verwendet, die komplexere Typen von Steuerflussen verwenden als geradlinige Codes. GenControl 
starlet mil einem einzelnen Basisblock und fuhrt eine bestimmte Anzahl von Transfonnalionen durch (zufallig gewahll). 
s Die Transfonnalionen, die derzeil durchgefuhrt werden, sind wie folgt: 
Ein Basisblock kann in zwei Basisblocke geteilt werden. 

Ein Basisblock kann durch ein Rbombuszeichen erselzt werden. Dies reprasentierl eine bedingte Verzweigung, wo 
sich die zwei Pfade wieder miteinander verbinden. 

Ein Basisblock kann durch eine Schleife ersetzt werden. 
hi Ein Basisblock kann durch drei Basisblocke ersetzt werden, wobei ein Funkiionsaufruf an den zweiten Basisblock er- 
lolgl. und zum dritlen zuruckspringl. 

Nachdem die spezifizierte Anzahl von Transfonnalionen an den Basisblocken durchgefuhrt wurde, exisliert ein zufal- 
\\n gcnerierter SteuerfluBgraph, der mil Instruktionen gefullt werden muB. Dies besleht aus zwei Teilen. Zur Generierung 
des*Codes fur die Basisblocke selbst werden die Einheiten zur Schaflfung eines Zufalls-K-OP-Codes verwendet, die im 
i> vorhergehenden Abschnirt diskutiert wurden. Der zweite Teil ist, Instruktionen zur Durchfuhrung der Verzweigungen 
und Schleifen einzufullen. Schleifen verwenden eine vordefinierte Schablone, die eine Anzahl von Malen iterien. Fur be- 
dingle Verzweigungen wird eine Zuf all stestinstrukt ion verwendet. 

KOMPILIERERCODEAUSZUGE 

I 'iir Diagnosezwecke und fiir Optimierungszwecke werden zahlreiche Codeauszugsmechanismen ini OOCn unter 
Windows verwendet. Es gibl zwei Hauptauszugsmechanismen. Erstens kann wahrend der Kompilierung ein Auszug ei- 
ncr ( odeliste vorgenommen werden, welche die K-OP-Codes enthall, die kompiliert werden, die IL, und (wenn er gene- 
ricrt wurdc) den Zielcode, Der zweite Typ eines Auszugs ist ein Auszug des Zielcodes in eine Assemblierungsform, die 
I ur Tesl/wccke ruckkompiliert und gegenverbunden werden kann. 

Durch das Vbrnehmen eines Auszugs einer Kopie des IL-Codes nach besliinnilen Slufen kann der Eflekt eines gege- 
benen Kompihcrcr-104-OpUmicrungsdurcnlaufs auf Korrckthcit und Effcktivitat untcrsucht werden. Fcrncr kann durch 
die I Jniersuchung des produzierten Endcodes manuell untersucht werden, wie gut der Kompilierer 104 jeden K-OP-Code 
in die IL ubersetzl, und die Qualitat des fur jede IL-Instruktion und jeden K-OP-Code produzierten Zielcodes. Diese 
( \\le-Aus/.uge werden unter Verwendung des COMBDUMP-Makros gesteuert, das zwischen Kompilierer-104-Durch- 
laufen in OOCT_Optimize_IL_And_Gen_Code eingefugt wird (siehe corapiler/ooct_trace.c). Dieses Makro ruft die 
(X K T Co mbdump-Prozedur auf (siehe ooct_combdump.c), die uber die K-OP-Codes und die IL-Instruktionen iteriert. 

Akmelle Profilierungswerkzeuge fur Windows behandeln dynamisch generierte Codes nicht korrekt. Daher wird der 
/.ucile Typ eines Auszugs verwendet, so dafi der dynamische Code von einem Lauf als statischer Code fiir eioen anderen 
;s 1 .auf verwendet und korrekt profiliert werden kann. Dies wird in zwei Schritten erreicht. Im ersten Schritt wird das Pro- 
izrumin mil der OC_DUMP-Flagge kompiliert (siehe compiler/ooct_dump.h), was bewirkt, daB jede K-OP-Code-Spm; 
die kompiliert ist, aufgezeichnet wird, und daB ein Auszug des Codes in eine Datei in einem ruckkompilierbaren Format 
vorgenommen wird. Zweitens wird das Programm kompiliert und mi t der OC_USEDUMP-Flagge laufen gelassen (siehe 
compilcr/ooct_dump.h), welche die dynamische Kompilierung fiir den vorher kompilierten Code anstelle der \ferwen- 
40 dung der statischen Version ausschaltet. Diese Version des Programms kann dann mit einem Profilierer laufen gelassen 
werden, urn eine Statistik liber die Qualitat des Codes aufzuzeichrien. 

ZWEITlt AUSFUHRUNGSFORM DER VORLIEGENDEN ERFINDUNG 

45 DYNAMISCHE OPTIMIERENDE OBJEKTCODE-UBERSETZUNG 

KIJRZFASSUNG DER ZWEITEN AUSFUHRUNGSFORM 

liine Architekturemulation ist die Imitation einer Computerarchitektur durch eine andere Computerarchitektuj; so daB 
50 der Maschinencodc fur die Originalarchiteklur ohne Modification laufen gelassen werden kann. Eine Objektcode-Uber- 
setzung ist der ProzeB der Ubcrsetzung eines Maschinencodes fiir eine Computerarchitektur in den Maschinencode fur 
cine andere Compuierarchitckiur. Das beschriebene dynamische optimierende Objektcode-Ubersetzungssystem verwen- 
dci Kompiliereroptimierungstechniken, um eine hohere Leistung zu erzielen als eine auf einer Schablone basierende Ob- 
jektcode-Ubersetzung fur eine Architekturemulation. 

55 BESCHREIBUNG VON FIGUREN DER ZWBITEN AUSFUHRUNGSFORM 

Fig. 23 veranschaulicht eine Systemkon figuration, die fur die dynamische optimierende Objektcode-Ubersetzung ge- 
maB der zweiten Ausfuhrungsform der vorliegenden Erfindung verwendet wird. Fig. 23 ist eine schematische Darstel- 
60 lung einer dynamischen Ubersetzung gleichzeitig mit der interpretierten Ausfiihrung von Programmer Jeder Tnterpre- 
tierer kann tJberselzungsanforderungen an den Kompilierer senden. Der Kompilierer macht dann einen ubersetzten Code 
fiir die Interpreuereraufgaben verfugbar. Auf einer Maschine mit mehrfachen Ausfuhrungseinheiten konnen alle Pro- 
zesse gleichzeitig ausfuhrcn. 

65 DETAILLTERTE BESCHREIBUNG DER ZWEITEN AUSFUHRUNGSFORM 

Das dynamische optimierende Objektcode-Ubersetzungssystem nimmt eine dynamische Kompilierung eines Instruk- 
tionssatzes in einen anderen vor, um eine Leistungsverbesserung gegenuber einer auf einer Schablone basierenden fJber- 
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seizung oder interpretierten Enl^^P>n vorzuschen. Das dynamische oprimierende fl^^ftcode-Oberseizungssy stern 
kombinien einc beliebige Anzahl von Interprelicrern, die cine Profilierung des laufenden Codes vornehnien, mit eincm 
geirennlen oplimierenden Konipilierer. Der optimicrendc Konipilierer verwendet die Profilierungsinforniationen aus 
dem laufenden Code, uni haufig ausgefuhrte Teile des Codes zu bestimmen. Diese Teilc werden dann kompiliert und den 
Inlerpretierern zur Venvendung geliefert. Die Gesamtstruklur des Systems ist in Fig. 23 gezeigt. 5 

Die Durchfuhrung bedeutender Optimierungen voni Kompilierer-Typ ist nur mil der Kenntnis des InstruklionsfluBgra- 
phen mdglich. In einem Iraditionellen Konipilierer ist der FluBgraph gegeben und gut definiert, da die gesamte Routine 
einer vollstandigen Sprachanalyse unterzogen wird, bevor die Optimierung beginnt. Flir ein Architekturemulationssy- 
stem ist. der zu kompilierende Code nicht verlugbar, bevor er tatsachlich laufen gelassen wird. Ferner konnen Instruktio- 
nen und Daten allgemein nicht differenziert werden, ohne daB tatsachlich ein Programm laufen gelassen wird. 10 

Daher muB zur Bestimmung des FiuBgraphen das Programm laufen gelassen werden. Ein Interpretierer wird verwen- 
det, urn das Programm das erste Mai laufen zu lassen. Wahrend der Interpretierer das Programm ausfuhrt, informiert er 
den dynamischen Konipilierer jedes ma 1, wenn er eine Verzweigungsoperation durchfuhrt. Diese Informationsprotokol- 
lierung identifiziert einige der Instruktionen und einige der Verbindungspunkte. Wahrend das Programm laufL, werden 
die Infonnationen liber den FiuBgraphen vollstandiger, obwohl sie nie ganz voilstandig werden. Das System ist ausgebil- 15 
del, mil Teilinformationen iiber den FiuBgraphen zu arbeiten: die Optimierung wird an potentiell un vollstandigen FiuB- 
graphen durchgefuhrt, und das System ist ausgebildet zu gestatten, daB ein optimierter Code ersetzt wird, wahrend mehr 
Infonnationen verfiigbar werden. 

Die dynamische Kompilierung wahlt, welche Teile des Texts zu optimieren sind, auf der Basis der voni Interpretierer 
gesarnmelten Profilierungsinforniationen. Wenn die Anzahl von Malen, die irgendeine Verzweigung ausgefiihrt wird, 20 
eine Schwelle uberschreitet, wird das Ziel dieser Verzweigung ein Startparameter zur Kompilierung. Der Starlparameter 
ist ein Startpunkt fur eine Sprachanalyse eines Teils der als Einheit zu kompilierenden Quelleninstruktionen. Diese Ein- 
heit wird als Segment bezeichnet. 

Ein Segment enthalt die Instruktionen, die aus der Optimierung der Quelleninstruktionen aus dem Startparameter re- 
sultieren. Es wird als Einheit installiert und deinstalliert. Wenn der Interpretierer den Kompilierer aufruft, um ihn uber 25 
eine Verzweigung zu infonnieren, kann er wahlen, die Sleuerung in das Segment zu transferieren, wenn der Code fur das 
Zicl cxisticrt. Ahnlich kann das Segment cincn Code fur den Transfer der Stcucrung zuruck zum Interpretierer cnthaltcn. 

Ein Segment kann unvollstandig sein, wobei es nur einen Subsatz der moglichen RuBpfade aus dem Quelienpro- 
gramm reprasentiert. Diese unvollstandige Reprasentation beeinfluBt jedoch nicht den korrekten Betrieb der Emulation. 
Wenn ein neuer, unvorhergesehener FluBpfad durch den Originalcode entsteht, dann springt der SteuerfluB zum Interpre- 30 
tierer zuriick. Spater kann dasselbe Segment ersetzt werden, um den neuen SteuerfluB zu berucksichtigen. 

BESONDEKE OBJEKTE DER ZWEITEN AUSFUHRUNGSFORM 

Die Erfindung ist die Venvendung der optimierten Objektcode-Ubersetzung fur eine verbesserte Leistung in Architek- 35 
turemuladonssystemen. 

ZUSAMMENFASSUNG DER ZWEITEN AUSFUHRUNGSFORM 

Das beschriebene dynamische optimierende Objektcode-t)bersetzungssystem verwendet Kompiliereroptimierungs- 40 
techniken, um eine hdhere Leistung zu erzielen als eine auf einer Schablone basierende Objektcode-ttbersetzung fur eine 
Architekturemulation. Die Erfindung ist die Venvendung der optimierten Objektcode-Ubersetzung fur eine verbesserte 
Leistung in Architekturemuladonssystemen. 

DROTE AUSFUHRUNGSFORM 45 

GLEICHZEITIGE DYNAMISCHE UBERSETZUNG 

KURZFASSUNG DER DRITTEN AUSFUHRUNGSFORM 

50 

Die dynamische Ubersetzung ist ein Akt der Ubersetzung eines Computerprogramms in einer Maschinensprache in 
eine andere Maschinensprache, wahrend das Programm lauft. Das beschriebene gleichzeitige dynamische Ubersetzungs- 
system fuhrt eine Ubersetzung gleichzeitig mit interpretierter Programmausfuhrung durch. 

BESCHREEBUNG VON FIGUREN DER DRITTEN AUSFUHRUNGSFORM 55 

Fig. 24 veranschaulicht eine Systemkonfiguration, die fUr die gleichzeitige dynamische Ubersetzung gemaB der drit- 
ten Ausfiihrungsform der vorliegenden Erfindung verwendet wird. Fig. 24 ist eine schematise he Darstellung einer dyna- 
mischen Ubersetzung gleichzeitig mit interpretierter Ausfuhrung von Programmen. Jede Interpretiereraufgabe kann 
Ubersetzungsanforderungen an die Kompiliereraufgabe senden. Die Kompiliereraufgabe macht dann den ubersetzten 60 
Code fur die Interpretiereraufgaben verfiigbar. Auf einer Maschine mit mehrfachen Ausfuhrungseinheiten konnen alle 
Prozesse gleichzeitig ausgefuhrt werden. 

Fig. 25 veranschaulicht den Unterschied zwischen der Kombination eines Interpretierers und Kompilierers, beispieis- 
weise wahrend der Ausfuhrung als eine Aufgabe, und ihrer Trennung, beispielsweise in verse hiedene Auf gaben, gemaB 
einer vierten Ausfuhrungsform der vorliegenden Erfindung. Fig. 25 ist eine schematische Latenzdarstellung mit kombi- 65 
nierten und getrennten Interpretierer- und Kompiliereraufgaben. 
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UNGSFORM 

Der Zweck der gleichzeitigen dynamischen Ubersetzung is!, eine Leistungsslcigerung gegenuber einem Interprelierer 
durch das Kompilieren eines Ausfuhrungsprogramms in eine effizientere Form, wahrend der Interpretierer noch lauft, 
5 vorzusehen. Zur Durchfiihrung der dynamischen Ubersetzung gleichzeitig mil der Ausfuhrung eines Interpret ierers lauft 
der Kompilierer als getrennle Aufgabe auf einem System mil mehrfachen Ausfuhrungseinheiten. Die Kompiliercrauf- 
gabe is! ein Server, der Antbrderungen zur Ubersetzung einiger Instruktionen cnipfangt, und mil einem Stiick ubersetzten 
Code antwortet. Die Anordnung des Kompiliererservers als getrennle Aufgabe hat einige Vorteile. Erstens kann mehr als 
eine Interpretiereraufgabe an denselben Server Antbrderungen stellen. Zweitens mussen die Interpreuererauigaben nicht 

to auf das Ergebnis einer Kompilierungsanforderung warien, bevor sie weitergehen. Drittens sind die Interprelierer und der 
Kompilierer gegen Fehler in anderen Aufgaben isoliert. Viertens konnen die Interpretierer und der Kompilierer unabhan- 
gig terminisiert werden, so daB die Arbeit gleichmaBiger uber die Anzahl verfugbarer Prozessoren aufgeteilt wird. Jeder 
dieser Vorteile wird nachstehend detail lierter beschrieben. 

Es gibt einige existierende dynamische Ubersetzungssysteme, die keine getrennten Kompiliereraufgaben haben. Die 

15 virtueile Java-Maschine von Sun Microsystems ist ein Beispiel [2], Der Interpretierer in der virtuellen Maschine kann 
eine dynamische Ubersetzungsanforderung ausgeben, indem er eine Prozedur aufruft. Der Interpretierer muB auf die 
Voliendung der Ubersetzungsanforderung warten, bevor er die Ausfuhmng des Programms fortsetzt. Ein weiteres Bei- 
spiel ist das dynamische OCT-Ubersetzungssystem von Fujitsu, das eine Seite von Instruktionen zu einer Zeit ubersetzt 
[ 1 ]. Im OCT-Ubersetzungssystem muB der Interpretierer auf die Voliendung der Ubersetzungsanforderung warten, bevor 

20 er die Ausfuhrung fortsetzt. 

Es sind auch IJbersetzungsserver fiir die statische t Jbersetzung des Java-Quellencodes in den Java-Bytecode verfugbar 
[3]. Diese Server bieten die Vorteile einer getrennten Kompiliereraufgabe zur stauschen Ubersetzung, jedoch nicht zur 
dynamischen Ubersetzung, da sie nicht operieren, wahrend das Java-Programm lauft. 

Der erste Vorteil der Anordnung der getrennten Kompiliereraufgabe ist, daB mehrfache Interpretiereraufgaben Uber- 

25 setzungsanforderungen an denselben Server stellen konnen. Sie mussen den Kompilierercode nicht in ihrem ausfuhrba- 
ren Bild enlhallen, wodurch es viel kleiner wird. Sie haben keine Cache- Konflikte zwischen Inlerpreuererinslrukuonen 
und Kompilicrcrinstruktioncn odcr zwischen Intcrprcticrcrdatcn und Kompilicrcrdatcn. Da auf nahczu alien modemen 
Prozessoren eine effiziente Cache-Nutzung wichtig ist, stellt dies einen signifikanten Vorteil dar. 

Der zweite Vorteil einer getrennten Kompiliereraufgabe ist, daB die Interpretierer die Latenz des Kompilierers nicht 

30 sehen. Fig. 25 veranschaulicht die Differenz der Latenz. Mit der kombinierten Interpretierer- und Kompiliereraufgabe 
fuhrt der Interpretierer keine Instruktionen aus, bis der Kompilierer die Ubersetzung der Instruktionen beendet hat. Mit 
den getrennten Aufgaben nimmt der Interpretierer sofort die Ausfuhrung von Instruktionen wieder auf, wahrend der 
Kompilierer arbeitet. Die gesamte von den getrennten Aufgaben verrichtete Arbeit ist groBer, da sie Ubersetzungsanfor- 
derungen senden und empfangen mussen, die geringere Latenz bedeutet jedoch, daB Benutzer des Systems keine Pausen 

3S einhalten, wahrend der Kompilierer arbeitet Die Interpretiereraufgabe kann auch auf exteme Ereignisse, wie Unterbre- 
chungen, reagieren, wahrend der Kompilierer arbeitet, was in der Anordnung der kombinierten Aufgaben nicht moglich 
sein kann. In der Praxis setzt die Tatsache, daB der Interpretierer die Latenz des Kompilierers in der kombinierten An- 
ordnung sieht, eine Grenze fur die Komplexitat des Kompilierers und die Qualitat des ubersetzten Codes. Beispielsweise 
sollten Java Just-In-Time-Kompilierer schnell genug ausfuhren, so daB ein mit dem Java-System interagierender Benut- 

40 zer keine Pause sieht, was einige komplexe Optimierungen ausscblieBt. Ahnhch fuhrt das OCT-System nur eine Opti- 
mierung innerhalb einer einzigen ubersetzten Instruktion durch, um die Kompilierungszeit zu reduzieren. Die Anord- 
nung der getrennten Kompiliereraufgabe enndglicbt eine Optimierung quer iiber mehrfache Instruktionen. 

Der dritte Vorteil der getrennten Kompiliereraufgabe ist, daB Fehler in den Interpretiereraufgaben und der Kompilie- 
reraufgabe voneinander isoliert werden. Dies bedeutet, daB, wenn die Kompiliereraufgabe eine Adressenausnahme oder 

45 Ausnahmebedingung erhalt, die Interpretiereraufgabe nicht beeintrachtigt wird. Der Kompilierer setzt sich selbst nach 
einem Fehler zuriick und setzt die Arbeit an der nachsten Anforderung fort. Da die Interpretiereraufgaben nicht warten, 
bis der Kompilierer eine Ubersetzungsanforderung beendet hat, merken sie nicht, wenn der Kompilierer einen Fehler er- 
halt. 

Der vierte Vorteil der getrennten Kompiliereraufgabe ist, daB sie die Belastung der Kompilierer- und Interpretiererauf- 
50 gaben ausgleichen kann. Im dynamischen Ubersetzungssystem gibt es Zeiten, wenn die Interpretiereraufgaben stark be- 
legt sind und alle CPUs des Computers benotigen, und es gibt Zeiten, wenn die Interpretiereraufgaben untatig sind und 
die CPUs nicht genutzt werden. In der kombinierten Interpretierer- und Kompiliereranordnung wird die meiste Kompi- 
lierungsarbeit verrichteU wenn die Interpretierer belegt sind, da der Kompilierer nur aufgerufen wird, wenn der Interpre- 
tierer lauft. Dies nutzt die untatigen CPU-Zyklen nicht aus. In der Anordnung der getrennten Kompiliereraufgabe setzt 
55 der Kompilierer die Arbeit fort, wenn die Interpretierer untatig sind. Sie produziert einen ubersetzten Code; den die In- 
terpretierer wahrscheinlich in der Zukunft verwenden werden. 

BESONDERE OBJEKTE DER DRITTEN AUSFUHRUNG SFORM 

60 Die dritte Ausfuhrungsform der vorliegenden Erfindung ist auf die Verwendung einer dynamischen Ubersetzung 
gleichzeitig mit mehrfachen Interpretierem, die auf einem System ausfuhren, mit mehrfachen physischen Ausfuhrungs- 
einheiten gerichtet, wobei eine kleinere ausfuhrbare BildgroBe, eine reduzierte Cache- Konkurrenz, eine geringere Inter- 
pretiererausfuhrungslatenz, eine Fehlerisolierung und ein besserer Belastungsausgleich vorgesehen werden. 

65 ZUSAMMENFASSUNG DER DRITTEN AUSFUHRUNGSFORM 

Das beschriebene dynamische Ubersetzungssystem fuhrt eine Ubersetzung gleichzeitig mit interpretierter Program- 
mausfuhrung durch. Das System verwendet einen getrennten Kompilierer, so daB er die Leistung der Interpretiererauf- 
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gaben nichl signifikanl beeinlrac^^^ Die Erfindung ist die Verwendung einer dynam^S^n Ubersetzung gleich/xilig 
mil mehrfachen Interpret ic rem, die auf eineni Sysiem ausfuhren, mil mehrfachen physischcn Ausfuhrungseinheiten, wo- 
bci eine klcincre ausfuhrbare BildgroGe, eine reduzierle Cache-Konkurrenz, eine geringerc Interpret iererausf uhrungsla- 
lenz, eine Fehlerisolierung und ein besserer Belastungsausgleich vorgesehen werden. 

VTERTE AUSFUHRUNGSFORM DER VORLTEGENDEN ERFINDUNG 

EMULATION WAHREND DER DYNAMISCHEN UBERSETZUNG, UM DIE BEL AS TUNG DER PROFILIE- 

RUNG AUF DEN EMULATOR ZU REDUZIEREN 

KURZFAS SUNG DER VTERTEN AUSFUHRUNGSFORM 



10 



Eine Architekturernulalion ist die exakte Imitation einer Compuierarchiteklur durch eine andere Computerarchitektur, 
so daB der Maschinencode fur die Origin alarchiteklur ohne Modifikation laufen gelassen werden kann. Eine Objektcode- 
Ubersetzung ist der ProzeB der Ubersetzung eines Maschinencodes fiir eine Computerarchitektur in den Maschinencode 15 
fiir eine andere Computerarchitektur. Das beschriebene dynamische optimierende Objektcode-Ubersetzungssystem ver- 
wendet Kompiliereroptimierungstechniken, urn eine hohere Leistung zu erzielen als eine auf einer Schablone basierende 
Objektcode-Ubersetzung fur eine Architekturemulation. Es ist jedoch eine Profilierung erforderlich, um die dynamische 
optimierende Objektcode-Ubersetzung zu realisieren. Die Beschreibung erlautert ein Verfahren zur Reduktion der Bela- 
stung der Profilierung. 20 

BESCHREIBUNG VON FIGUREN DER VTERTEN AUSFUHRUNGSFORM 

Fig. 26 veranschaulicht eine Ubersetzungstabelle, die verwendet wird, um aufzuzeichnen, welche Instruktionen iiber- 
setzbar sind und welche nicht, gemaB einer vierten Ausfuhrungsform der vorliegenden Erfindung. Fig. 26 ist eine Uber- 25 
selzungslabelle, die zeigt, welche Prograiimie ubersetzbar sind und welche nicht. In diesem Fall werden Programme in 
Einhcitcn von I Bytes gemcsscn. Der Emulator priift, wclchcm Eintrag cin Vcrzwcigungsnachfolgcr cntspricht, wodurch 
bestirnmt wird, ob er zu einem ubersetzbaren Programm springt oder nicht. 

Fig. 27 veranschaulicht, wie das Verfahren die Belastung der Profilierung auf den Emulator gema6 einer vierten Aus- 
fuhrungsform der vorliegenden Erfindung reduziert. Fig. 27 ist ein RuBdiagramm, das zeigt, wie der Emulator die Pro- 30 
tokollierung fiir ubersetzbare Programme einschaltet, und wie er sie fiir nicht-ubersetzbare Programme ausschalteL Die 
Trigger *1- und Trigger *2-Instruktionen sollten beide protokolliert werden, die Trigger *l-Instruktion kann jedoch nicht 
zwischen einem ubersetzbaren Programm und einem nichtiibersetzbaren Programm springen. Nur die Trigger *2-In- 
struktion kann zwischen ihnen springen. Die Protokollflagge, die sich merkt, ob der Emulator in einem ubersetzbaren 
oder nicht-ubersetzbaren lauft . Daher muB der Emulator bei Trigger * 1 -Instruktionen nicht die Ubersetzungstabelle prii- 35 
fen oder die Protokollflagge andem. Er priift nur, ob die Verzweigungsnachfolgerinstruktion bereits kompiliert wurde, 
und springt sofort zum kompilierten Code. Da Trigger *1 -Instruktionen die am haufigsten venyendeten Trigger-Instruk- 
tionen reprasentieren, kann dieser Algorithmus die Belastung der Profilierung auf die Emuladon reduzieren. 

DETAILLIERTE BESCHREIBUNG DER VIERTEN AUSFUHRUNGSFORM 40 

Die dynamische opdnuerende Objektcode-Ubersetzung realisiert eine hohe Leistung durch die Produkuon schnellerer 
Instruktionen, sie fuhrt jedoch zu Kosten hinsichtlich Speicher und Zeit. Daher werden in einer Architekturemulation so- 
wohl die dynamische opumierende Objektcode-Ubersetzung als auch die Emuladon gemeinsam verwendet. Die Uber- 
setzung wird fur das Hauptprogramm verwendet, das haufig lauft und eine hohe Leistung benotigt. Und der Emulator ar- 45 
beitet fur kleinere Programme und auch zur Profilierung des Hauptprogramms, bis der Ubersetzer die Kompilierung voll- 
endet. Ein Profil wird vom Ubersetzer verwendet, um das Programm zu kompitieren und zu optimieren. 

Insunktionen, die von einem nicht-ubersetzten Code zu einem iibersetzten Code springen konnen, werden als Trigge- 
rinstruktionen bezeichnet. Wenn eine Triggerinstruktion von einem Nebenprogramm zu einem Hauptprogramm oder von 
einem Hauptprogramm zu einem Nebenprogramm springen kann, wird sie Trigger *2-Instruktion genannt. Wenn sie nur 50 
innerhalb eines Nebenprogramms oder eines Hauptprogramms springen kann, wird sie Trigger *l-Instruktion genannt. 
Da der Ubersetzer nicht auf den Nebenprogrammen arbeitet, ist es nichl notwendig, die Trigger *1 -Instruktionen in ei- 
nem Nebenprogramm zu profilieren. Es ist notwendig. Trigger * 1 -Instruktionen in einem Hauptprogramm zu profilieren, 
da ein Teil des Programms iibersetzt sein kann, wahrend ein anderer Teil noch nicht iibersetzt ist. Es ist notwendig, Trig- 
ger *2-Instruktionen sowohl in Neben- als auch Hauptprogrammen zu profilieren, da sie in ein anderes Hauptprogramm 55 
springen konnten. 

Die Emulation nimmt drei Priifungen nach der Ausfuhrung einer Trigger *2-Instruktion vor (siehe Fig. 27). Zuerst 
priift sie, ob der Ubersetzer ein ist. Wenn er ein ist, pruf t sie, ob der Nachfolger der Trigger *2-Instruktion ubersetzbar ist 
oder nicht. Wenn er ubersetzbar ist, dann setzt die Emulation die Protokollierflagge auf wahr und priift, ob der Nachfol- 
ger iibersetzt wurde, wobei sie zur ubersetzten Version springt., wenn diese exist.iert. 60 

Die Emulation nimmt nur zwei Priifungen nach der Ausfuhrung einer Trigger *l-Instruktion vor (siehe Fig. 27). Zu- 
erst priift sie, ob die Protokollierflagge ein oder aus ist. Wenn sie Flagge aus ist, dann ist diese Instruktion in einem Ne- 
benprogramm, und sie muB nicht proftliert werden. Wenn die Flagge ein ist, dann pruft die Emuladon, ob ihr Nachfolger 
iibersetzt wurde oder nicht. 

Haupt- und Nebenprogramme werden durch ihre Speicheradressen unterschieden (siehe Fig. 27). Der Emulator ver- 65 
wendet eine Ubersetzungstabelle, um die Beziehung von ubersetzbaren und nicht-iibersetzbaren Programmadressen auf- 
zuzeichnen. Fur Trigger *1 -Instruktionen, die sich niemals zwischen ubersetzbaren Programmen und nicht-iibersetzba- 
ren Programmen bewegen, muB der Emulator nicht auf die t Jbersetzungstabelle zugreifen, da die Protokollierflagge 
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reirWnthall. 
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35 



50 



diese Infonnationen bcreiT 

Durch die Trennung des Verhaltensdcs Emulators fur Trigger *1- und Trigger *2-Insiruktionen in zwei Verfahren wird 
die Belastung der Profilierung auf die Emulation reduziert. 

S BESONDERE OBJEKTE DER VTERfEN AUSFUHRUNGSFORM 

Die vierle Ausfuhrungsforni der vorliegenden Erfindung ist auf ein Verfahren zur Reduktion der Belastung der Profi- 
lierung auf den Emulator gerichtet, indem ein Code nach Triggerinslruktionen plaziert wird, die in und aus ubersetzbaren 
Instruktionen springen konnen, der priift, ob der Verzweigungsnachfolger ubersetzbar ist. oder nicht, und indem ein Code 
10 nach alien anderen Triggern plaziert wird, der nur eine Flagge pruft, uni zu sehen, ob sie ubersetzbar isi oder nicht". 

ZUSAMMENFASSUNG DER VTERTEN AUSFUHRUNGSFORM 

Es ist effektiv, die dynamische Objekteode-Ubersetzung zusammen mit der Emulation zu verwenden, aber die Kosten 
15 von Profikerungsinstruktionen zur Fuhrung des Ubersetzers sind eine Belastung fur die Emulation. Durch die Unter- 
scheidung zwischen verschiedenen Typen profilierter Instruktionen ist es moglich, diese Belastung zu reduzieren. Die 
Erfindung ist ein Verfahren zur Reduktion der Belastung der Profilierung auf den Emulator, indem ein Code nach Trig- 
ger-Instruktionen plaziert wird, die in und aus ubersetzbaren Instruktionen springen k6nnen, der priift, ob der Verzwei- 
gungsnachfolger ubersetzbar ist oder nicht, und indem ein Code nach alien anderen Triggern plaziert wird, der rtur eine 
20 Flagge priift, urn zu sehen, ob sie ubersetzbar ist oder nicht. 

FUNFTE AUSFUHRUNGSFORM DER ERFINDUNG 

SOFTWARE-RUCKKOPPLUNG FUR DIE DYNAMISCHE UBERSETZUNG 

KURZFASSUNG DER FUNFTEN AUSFUHRUNGSFORM 



Die dynamische Ubersetzung ist ein Akt der Ubersetzung eines Computerprogramrns in einer Maschinensprache in 
eine andere Maschinensprache, wahrend das Programm lauft. In einigen dynamischen Ubersetzungssystemen ist die 
30 Aufgabe, die das Programm laufen laBt, Interpretierer genannt, von der Aufgabe, die das Programm iibersetzt, Kompi- 
lierer genannt, getrennt. Die Rate, bei welcher der Interpretierer Anforderungen an den Kompilierer sendet, sollte mit der 
Rate ubereinstimmen, bei welcher der Kompilierer die Anforderungen vollendet. Auch sollte die Rate, bei welcher der 
Interpretierer Anforderungen sendet, nicht auf Null fallen. Die Software-Riickkopplung sieht einen Weg zurn Ausglei- 
cben der beiden Raten vor. 



BESCHREIBUNG.VON FIGUREN DER FUNFTEN AUSFUHRUNGSFORM 



Fig. 28 veranschaulicht eine allgemeine Strukturdarstellung eines dynamischen Ubersetzungssystems mit getrenntem 
Interpretierer und Kompilierer gemaB einer funften Ausfuhrungsform der vorliegenden Erfindung. Fig. 28 ist eine Struk- 

40 turdarstellung eines dynamischen Obersetzungssy stems. Der Interpretierer sendet Ubersetzungsanforderungen' an den 
Kompilierer. Der Kompilierer sendet einen ubersetzten Code als Antwort zuruck. Die Raten der Anforderungen und Ant- 
worten sollten gleich sein, damit das System am effizientesten lauft. 

Fig. 29 veranschaulicht Komponenten eines Software-Ruckkopplungsmechanismus gemaB einer funften Ausfuh- 
rungsform der vorliegenden Erfindung. Fig. 29 ist eine Darstellung, die Komponenten eines Software-Ruckkopplungs- 

45 systems veranschaulicht. Die Vergleichsprozedur subtrahiert die Anzahl der Vollendungen von der Anzahl der Anforde- 
rungen. Die Anforderungsratenprozedur stellt die Rate auf der Basis dieser Diflferenz ein. Die Anforderungssendeproze- 
dur sendet Anforderungen in Abhangigkeit von der aktnellen Rate. 



DETAJLUERTE BESCHREEBUNG DER FUNFTEN AUSFUHRUNGSFORM 



In einem dynamischen Ubersetzungssystem sendet die Interpretiereraufgabe Anforderungen an die Kompiliererauf- 
gabe. Die Anforderungen enthalt Informationen, um dem Kompilierer mitzuteilen, welcher Abschnitt des Programms zu 
ubersetzen ist. Der Kompilierer iibersetzt den Abschnitt und antwortet mit einem ubersetzten Code. Das Problem der 
Entscheidung, wann eine Anforderung zu senden ist, ist ein Beispiel eines Terminisierungsproblems. Die Rate, bei wel- 
55 cher die Interpretiereraufgabe Anforderungen stellt, sollte mit der Rate ubereinstimmen, bei welcher der Kompilierer 
Anforderungen beendet. So wird der Kompilierer nicht untatig oder mit Anforderungen uberladen. 

Die Software-RUckkopplung ist ein Verfahren zum Ausgleichen der Raten von zwei Ereignissatzen [1]. Im dynami- 
schen Ubersetzungssystem andert sie die Rate von Ubersetzungsanforderungen, um gleich der Rate vollendeter tiberset- 
zungen zu sein. Wie in Fig. 29 gezeigt hat das Software-Ruckkopplungssystem drei Hauptteile. Der erste ist eine Proze- 
60 dur zum Vergleichen der Anzahl von Ubersetzungsanforderungen und der Anzahl vollendeter Ubersetzungen. Der 
zweite ist eine Prozedur, welche die Rate von Ubersetzungsanforderungen auf der Basis des Ergebnisses des Vergleichs 
andert. Der dritte Teil ist eine Prozedur, um die Ubersetzungsanforderungen zu stellen, die vom Ausgang der zweiten 
Prozedur abhangig sind. 

Im dynamischen Ubersetzungssystem zahlt die Interpreuereraufgabe, wie oft eine Verzweigungsinstruktion zu einer 
65 bestimmten Zieladresse springt. Wenn diese Zahlung eine Schwelle uberschreitet, sendet der Interpretierer eine Uberset- 
zungsanforderung, welche die Zieladresse enthalt Der Schwellenwert ist der kritische Parameter, der vom Software- 
Riickkopplungsmechanismus eingestellt wird. Wenn die Schwelle niedriger ist als die meisten der Ausfuhrungszahlun- 
gen, ist die Rate von t Ubersetzungsanforderungen hoch. Wenn die Schwelle hoher ist ais die meisten der Ausfuhrungs- 
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y.iihlungen, isl die Rale von An^^fcungen niedrig. Da die lypische GroBe einer Au^j^jngszahlung mil deni Pro- 
granim, das inlcrprei.iert wird, varrerl, isl die Software-Riickkopplung ein idealer Weg, die Schwelle einzusicllen, da sic 
sich an das Verhalien des Inierpretierers automat isch anpaBl. 

Ini dynamischen Uberselzungssystem ist die Vergleichsprozedur des Software-Ruckkopplungssyslems sehr einfach. 
Sic bercchnet nur die Different zwischen der Anzahl von an den Kompilierer gesendeten Ubersetzungsanforderungen s 
und die Anzahl vollendeler Ubersetzungen. 

Die Anforderungsraienprozedur anderl den Schwellenwert auf der Basis der von der Vergleichsprozedur berechnelen 
Diffcrenz. Wenn die Differenz Null ist, dann ist die Schwelle zu hoch und hinder! den Interpretierer daran, Ubersetzungs- 
anforderungen zu senden. In diesem Fall subtrahien die Anforderungsraienprozedur eine Konstanlc von der Schwelle. 
Wcnn die Differenz ihr maximal moglicher Wert isl, dann isl die Schwelle zu niedrig, und der Interpretierer sendet zu 10 
vide Uberselzungsanforderungen. In diesem Fall addiert die Anforderungsraienprozedur eine Konslante zur Schwelle. 

Die Anforderungssendeprozedur wird aufgerufen, wenn der Inlerprelierer eine Verzweigungsinstruktion ausfuhrt. 
Wcnn die Verzweigungsinstruktion mehrere Male zur gleichen Zieladres.se gesprungen ist als die Schwelle, sender der 
Inlcrpretierer eine Ubersetzungsanforderung, welche die Zieladresse enlhall. 



BESONDERE OBJEKTE DER FUNFTEN AUSFUHRUNGSFORM 



ZUSAMMENFASSUNG DER FUNFTEN AUSFUHRUNGSFORM 



15 



Die Erfindung ist die Verwendung eines Software-Ruckkopplungsmechanismus in einem dynamischen Ubersetzungs- 
sysicin mit getrennten Interpretierer- und Kompiliereraufgaben, um die Rate von vom Interpretierer gesendeten tjberset- 
y.ungsanforderungen und die Rate von vom Kompilierer voilendeten Ubersetzungen auszugleichen, ohne zu emiogli- 20 
ch e n . daB der Kompili erer untatig wird. 

Die Verwendung einer minirnalen Schwelle, um dem Kompilierer zu ermoglichen, den Betrieb einzustellen. ; 



25 



In einem dynamischen Uberselzungssystem mil gelrennten InLerprelierer- und Kompiliereraufgaben sollte die RaLe, 
bei wclchcr der Interpretierer Anforderungen an den Kompilierer sendet, mit der Rate ubcrcinstimmcn, bci wclchcr der 
Kompilierer die Anforderungen vollendet. Auch sollte die Rate, bei welcher der Interpretierer Anforderungen sendet, 
nichl auf Null fallen. Die Erfindung ist die Verwendung eines Software-Ruckkopplungssystems in einem dynamischen 
Uberselzungssystem mit getrennten Interpretierer- und Kompiliereraufgaben, um die Rate von vom Interpretierer gesen- 30 
dcicn Ubersetzungsanforderungen und die Rate von vom Kompilierer voilendeten Ubersetzungen auszugleichen, ohne 
zu ermoglichen, daB der Kompilierer untatig wird. 



35 



SECHSTE AUSFUHRUNGSFORM DER ERFINDUNG 

1 -INK! illlEN VON ANFORDERUNGEN DM EINE WARTESCHLANGE FUR DIE DYNAMISCHE UBERSETZUNG 

KURZFASSUNG DER SECHSTEN AUSFUHRUNGSFORM 

Die dynamische Obersetzung ist ein Akt der "Obersetzung eines Computerprogramms in einer Maschinensprache in 40 
cine andere Maschinensprache, wahrend das Programm lauft. Fur jedes Teilstuck des Programrns, das ubersetzt wird, 
si ell i das System eine Anforderung an den dynamischen Ubersetzer. Anforderungen, die gestellt werden, wahrend der 
dynamische Ubersetzer belegt ist, werden in eine Warteschlange eingereiht und ausgegeben, wenn der Ubersetzer untatig 
wird. Die Implementation des Einreihens in eine Warteschlange kombiniert Systemaufrufe und gemeinsam genutzte 
Speichcrkommunikation, zum Reduzieren. 45 

BESCHREIBUNG VON FIGUREN DER SECHSTEN AUSFUHRUNGSFORM 

Fig. 30 veranschaulicht, wie eine Warteschlange verwendet wird, um Ubersetzungsanforderungen zu halten, wahrend 
die t Jbersctzungsaufgabe belegt ist, gemaB einer sechsten Ausfuhrungsform der vorliegenden Erfindung. 50 

Fig. 3 1 veranschaulicht, wie die OOCT-Anforderungswarteschlange kostengiinstige gemeinsam genutzte Speicheran- 
fordcrungen mit Systemaufrufanforderungen gemaB einer sechsten Ausfuhrungsform der vorliegenden Erfindung kom- 
biniert. 

DETATLLIERTE BESCHREIBUNG DER SECHSTEN AUSFUHRUNGSFORM 55 



Die Grundfunkuon der Anforderungs warteschlange ist, sich Anforderungen zu merken, die gestellt werden, wahrend 
der dynamische Ubersetzer belegt ist, wie in Fig. 30 gezeigt. In jedem dynamischen Ubersetzungssystem gibt es eine 
Obergrenze der Anzahl von Ubersetzungen, die gieichzeitig durchgefuhrt werden konnen. Typischerweise ist die Grenze 
nur eine Ubersetzung zu einer Zeit. Rs besteht jedoch keine Grenze fur die Gesamianzahl gestellter Anforderungen oder 60 
die Rate, bei der sie gestellt werden. Daher ist es sehr wahrscheinlich, daB eine Ubersetzungsanforderung eintreten wird, 
wahrend der "Ubersetzer bereits belegt ist. Mit einer Anforderungswarteschlange wird die Ubersetzungsanforderung in 
eine Warteschlange eingereiht und rnuB nicht wiederholt werden. Wenn der Ubersetzer die Anforderung aus der Warte- 
schlange nimmt, wird er die Ubersetzung durchfuhren. 

Im OOCT hat das dynamische Ubersetzungssystem mehrfache Aufgaben, wobei eine die dynamische Ubersetzungs- . 65 
aufgabe ist, die Anforderungen behandelt, und andere die Ausfuhrungsaufgaben sind, die Ubersetzungsanforderungen 
stellen. Die OOCT-Implementation des Einreihens in eine Warteschlange verbessert eine naive Warteschlange unter Ver- 
wendung von weniger kostspieligem, gemeinsam genutzteni Speicher zusammen mit Systemaufrufnachrichten, um die 
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Anforderungswarteschlan^Ki bilden, wic in Fig. 31 gezeigt. Syslemaufrufe alll^Rid ausreichend, um Siartparameler 
von den Ausfuhrungsaufgaben zur Ubersetzungsaufgabe zu kommunizieren, und uni es der Ubersetzungsaufgabe zu er- 
moglichen, untatig zu werdem oder zu blockieren, wenn es keine ausstehenden Anforderungen gibl. Systemaufrufe sind 
jcdoch kostspieiige Operaiionen. Der gemeinsain genulzle Speicher kann verwendet werden. uni die Anforderungsnach- 
5 richlen von den Ausfuhrungsaufgaben zur Ubersetzungsaufgabe zu kommunizieren, die Ubersetzungsaufgabe kann je- 
doch diese Nachrichlen nicht blockieren, so daB sie konlinuierlich laufen muBlc, um Nachrichlen von einen) einfachen 
gemeinsain genutzten Speicher zu empfangen. 

Die OOCT-Implementation verwendet die besien Merkmale jedes Mechanism us, Systemaufruf und gemeinsam ge- 
nutzler Speicher. Sie ermoglicht es der Ubersetzungsaufgabe zu blockieren, wahrend sie auf eine Syslemaufrufnachricht 
10 warier, koimnunizien jedoch Anforderungen durch den gemeinsam genuizien Speicher, wenn die Ubersetzungsaufgabe 
bereits arbeitet. 

Wie in Fig. 31 gezeigt, verwendet die OOCT-Anforderungswarteschlange zwei Arten von Nachrichlen zwischen den 
Ausfuhrungs- und Uhersetzungsaufgahen, plus einen gemeinsam genutzten Speicherpuffer, auf den von beiden Aufga- 
ben zugegriffen wird. Die erste Nachricht geht von der Ubersetzungsaufgabe zur Ausfuhrungsaufgabe. Sie teilt der Aus- 

15 fiihrungsaufgabe mit, einen Systemaufruf zum Senden der nachsten Anforderung zu yerwenden. Diese Nachricht infor- 
miert die Ausfuhrungsaufgabe, daB die Ubersetzungsaufgabe den gemeinsam genutzten Speicherpuffer endeert hat und 
nun blockieren wird. Dann sendet die Ausfuhrungsaufgabe eine Anforderung nut einem Systemaufruf. Die Uberset- 
zungsaufgabe empfangt die Nachricht und beginnt eine Obersetzung. Nach dem Senden einer Anforderung nut einem 
Systemaufruf weiB die Ausfuhrungsaufgabe, daB die Ubersetzungsaufgabe belegt ist, daher sendet sie weitere Anforde- 

20 rungen direkt an den gemeinsam genutzten Speicherpuffer. Dies ist viel weniger kostspielig als die Verwendung eines 
weiteren Systeniaufrufs. Wenn die t jbersetzungsaufgabe eine Anforderung beendet, sieht sie im gemeinsam genutzten 
Speicherpuffer nach. Wenn sich in dem Puffer eine Anforderung befindet, wird sie entfernt und ubersetzt Wenn der ge- 
meinsam genutzte Speicherpuffer leer ist, teilt die tjbersetzungsaufgabe wieder der Ausfuhrungsaufgabe mit, einen Sy- 
stemaufruf zu verwenden. 

25 Die Vorteile der OOCT-Anforderungswarteschlange sind, daB die Ausfuhrungsaufgaben einen gemeinsam genutzten 
Speicher verwenden konnen, wenn sie Anforderungen bei einer hohen Rale senden, und die Ubersetzungsaufgabe blok- 
kicrcn kann, wenn Anforderungen bei einer langsamcn Rate ankommcn. 
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Dieser Anspruch ist eine Ubersetzung des Fujitsu-Patents auf japanisch, wobei ein Absatz hinzugefugt ist. 
Die Erfindung ist ein Verfahren zum Fortsetzen einer Interpretation, wahrend die Ubersetzung haufig verzweigter In- 
struktionen gestartet wird, indem eine Nachricht an die Ubersetzungsaufgabe gesendet wird, und zum Einreihen von 
Nachrichten an die Ubersetzungsaufgabe in eine Warteschlange, wenn eine Ubersetzung bereits begonnen hat, und eine 
35 Leistungsverbesserung gegenuber der Verwendung von sowohl Systemaufruf- als auch gemeinsam genutzten Speicher- 
mechanismen, um die Ubei^etzungsanforderungsnachrichten zu senden. 

ZUSAMMENFASSUNG DER SECHSTEN AUSFUHRUNGSFORM 

40 Die beschriebene tJbersetzungsanforderungswarteschlange ist ein Mechanismus zum Sammeln von Ubersetzungsan- 
forderungen, wahrend eine andere Ubersetzung ausfuhrt. Sie ermoglicht, daB die Ausfuhrungsaufgaben unmittelbar nach 
dem Senden einer Anforderung weiterlaufen. Durch die Verwendung sowohl von einem gemeinsam genutzten Speicher 
als auch Systemaufrufen miteinander ist es moglich, die Effizienz der Ubersetzungswarteschlange zu verbessem. Die Er- 
findung ist ein Verfahren zum Fortsetzen einer Interpretation, wahrend die Ubersetzung haufig verzweigter Instruktionen 

45 gestartet wird, indem eine Nachricht an die Ubersetzungsaufgabe gesendet wird, und zum Einreihen von Nachrichten an 
die Ubersetzungsaufgabe in eine Warteschlange, wenn eine Ubersetzung bereits begonnen hat, und eine Leistungsver- 
besserung gegenuber der Verwendung von sowohl Systemaufruf- als auch gemeinsam genutzten Speichermechanismen, 
um die Ubersetzungsanforderungsnachrichten zu senden. 

so SIEBENTE AUSFUHRUNGSFORM DER VORLIEGENDEN ERFINDUNG 

SETTENFEHLERBEHEBUNG FUR DIE DYN AMIS CHE UBERSETZUNG 

KURZFASSUNG DER SIEBENTEN AUSFUHRUNGSFORM 

Die dynamische Ubersetzung ist ein Akt der Ubersetzung eines Computerprograrnms in einer Maschinensprache in 
eine andere Maschinensprache, wahrend das Programm laufu Der dynamische Ubersetzer muB die Quellenmaschinenin- 
struktionen lesen, bevor er sie in Zielmaschineninstruktionen ubersetzt. Wahrend die Quelleninstruktionen gelesen wer- 
den, kann der Ubersetzer einen Seitenfehler verursachen, indem er aus einem Speicher liest, der ausgelagert ist, es ist je- 
60 doch ineffizient, den Speicher einziilagern. Der beschriebene Ubersetzer behebt Seitenfehler, ohne die ausgelagerten Da- 
ten zu lesen, und setzt die Ubersetzung fort 

BESCHREIBUNG VON FIGUREN DER SIEBENTEN AUSFUHRUNGSFORM 

65 Fig. 32 zeigt, wie ein dynamischer Ubersetzer wahrscheinlich Seitenfehler verursachen kann, die wahrend der norma- 
len Ausfuhrung der Quelleninstruktionen nicht eintreten wiirden, gemaB einer siebenten Ausfuhrungsform der vorliegen- 
den Erfindung. 

Fig. 33 zeigt den Algorithmus zur Behebung von Seitenfehlem wahrend der tJbersetzung und zum Fortsetzen der 
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Ubersetzung gemaB einer sieben^^ptsfuhrungsfonn der vorliegenden Erfindung. 

DETAELLEERTE BESCIIKEEBUNG DER SEEBENTEN AUSFUHRUNGSFORM 

Ein dynamischer Ubersetzer wird sehr wahrscheinlich auf Seiten zugreifen, die schiechle Kandidaten fiir das Kopieren 5 
in einen physischen Speicher sind, da er alle der moglichen Nachfolger einer Instruktion lies! und nicht nur die Nachfol- 
i ger, die tatsachlich ausgefuhrt werden. Beispielsweise, wie in Fig. 32 gezeigt, haben bedingte Verzweigungsinstruktio- 

nen zwei Nachfolger, den Fehlschlag-Nachfolger und den Verzweigung-eingeschlagen-Nachfolger. Wenn eine CPU eine 
bedingte Verzweigungsinstruktion ausruhrt, wenn die Verzweigung nichl eingeschiagen wird, dann wird die Verzwei- 
gung-eingeschlagen-Nachfolgerinstruktion niemals geladen. Daher wird sie keinen Seitenfehler verursachen. Wenn der 10 
dynaniische Ubersetzer die Verzweigungsinstruktion liest, versucht er, sowohl den Fehlschlag- als audi den Verzwei- 
gung-eingeschlagen-Nachfolger zu lesen, obne zu wissen, welcher tatsachlich ausgefuhrt wird. Er konnte einen Seiten- 
fehler verursachen, um die Verzweigungsnachfolgerinstruktion zu lesen, auch wenn sie niemals ausgefuhrt wird. 

Das norniale Verfahren zur Behandlung von Seitenfehlern ist, eine Seite in den angeforderten Speicher einzulagem, 
und den Speicherzugriff iiber Software vorzunehmen, und dann der Ausfuhrung zu gestatten, nach der fehlerhaften In- 15 
struktion fortzusetzen. Dieses Verfahren hat zwei Nachteile. Erstens braucht es Zeit, eine Seite vom physischen Speicher 
zum Sicherungsspeicher zu bewegen, und eine andere vom Sicherungsspeicher zum physischen Speicher zu bewegen, 
und dann den Speicherzugriff durchzufuhren. Zweitens wird der Satz von Speicherseiten, die darin eingelagert sind, ge- 
andert. Auf die Seite, die in den physischen Speicher kopiert wird, kann seiten zugegriffen werden, bevor sie wieder aus- 
gelagert wird, was bedeuten wiirde, daB es eine schlechte Idee war, sie in den physischen Speicher zu kopieren. 20 

Da der dynamische Ubersetzer haufigere Seitenfehler verursachen kann, ist es vorteilhaf t, die Kosten dieser Seitenfeh- 
ler zu reduzieren. Der dynamische Ubersetzer minimiert die Kosten zusatzlicher Seitenfehler, indem er eine neue Seite 
nicht in den physischen Speicher kopiert, und eine Seite, die bereits im physischen Speicher ist, nicht entfemt. Dies spart 
die Kopierzeit und steilt auch sicher, daB eine Seite, auf die seiten bezuggenommen wird, nicht einkopiert wird. Ans telle 
des Kopierens der Seite unterbricht der Seitenfehler-Handler den aktuellen Strom von Instruktionen im Ubersetzer und 25 
fiihrt die Sleuerung zu einein vom Ubersetzer vorgegebenen Priifpunkt zuruck. 

Der Ubersetzer licst Qucllcninstruktioncn in Einhcitcn, die Basisblocke genannt werden. Wenn ein Seitenfehler cin- 
tritt, wahrend er einen Basisblock liest, dann ignoriert der Ubersetzer diesen Block, setzt jedoch die Ubersetzung irgend- 
welcher anderen Blocke fort. Nachdem alle Basisblocke gelesen wurden, werden sie in einen Satz von Zielinstruktionen 
ubersetzL Das Verfahren des Ignorierens eines Basisblocks, der einen Seitenfehler verursacht, ist in Fig. 33 gezeigt. Be- 30 
vor er einen Basisblock liest, legt der Ubersetzer einen Priifpunkt fest. Alle vor dem Priifpunkt gelesenen Basisblocke 
sind sicher und konnen von keinerlei Seitenfehlem beeintrachtigt werden, die nach dem Priifpunkt geschehen. Dann ver- 
sucht der Ubersetzer, den nachsten Basisblock zu lesen. Wenn es einen Seitenfehler gibt, springt er sofort zum Priifpunkt. 
Dadurch wird er veranlaBt, den Basisblock zu uberspringen und zu versuchen, den nachsten zu lesen. 

35 

BESONDERE OBJEKTE DER SIEBENTEN AUSFUHRUNGSFORM 

Die Erfindung gemaB der siebenten Ausfuhrungsform ist ein Weg, die Speicherzugriff skos ten der dynamischen Uber- 
setzung zu reduzieren, indem Seiten nicht in den physischen Speicher kopiert werden, wahrend weiterhin gestattet wird, 
daB die Oberselzung fortgesetzt wird, wenn ein Speicherzugriff fehlschlagt. 40 

ZUS AMMENFAS SUNG DER SIEBENTEN AUSFUHRUNGSFORM 

Der beschriebene Mechanismus zum Beheben von Seitenfehlem ist ein Weg, die Kosten der dynamischen Uberset- 
zung zu reduzieren, wenn auf einen nicht-physisch abgebildeten Speicher zugegriffen wird. Er ermoglicht, daB die dyna- 45 
mische Ubersetzung fortgesetzt wird, auch wenn nicht alle der Quellenmaschineninstrukdonen aufgrund von Seitenfeh- 
lem gelesen werden konnen. Die Erfindung ist ein Weg, die SpeicherzugrifFskosten der dynamischen Ubersetzung zu re- 
duzieren, indem Seiten nicht in den physischen Speicher kopiert werden, wahrend weiterhin gestattet wird, daB die Uber- 
setzung fortgesetzt wird, wenn ein Speicherzugriff fehlschlagt. 

50 

ACHTE AUSFUHRUNGSFORM DER VORLIEGENDEN ERFINDUNG 

AUFZEICHNUNG VON AUSG ANGEN AUS DEM UBERSETZTEN CODE FUR DIE DYNAMISCHE UBERSET- 
ZUNG 

55 

KURZFASSUNG DER ACHTEN AUSFUHRUNGSFORM 

Die dynamische Ubersetzung ist ein Akt der Obersetzung eines Computerprograrnins in einer Maschinensprache in 
eine andere Maschinensprache, wahrend das Programm lauft. Der dynaniische Ubersetzer wahlt die zu ubersetzenden In- 
struktionen, indem er sie profiliert, wahrend sie ausfuhren. Die haufig ausgefuhrten Tnstruktionen werden ubersetzt, und 60 
die seiten ausgefuhrten werden dies nicht. Die ubersetzten Instruktionen konnen bewirken, daB der Profilierer einige In- 
struktionen auslafit, was dazu fuhren kann, daB haufig ausgefuhrte Instruktionen interpretiert werden. Durch die Auf- 
zeichnung spezifischer Ausgange aus dem ubersetzten Code ist es moglich, alle der haufig ausgefuhrten Instruktionen zu 
profilieren und sicherzustelien, daB sie alle iibersetzt werden. 

65 

BESCHREIBUNG VON HGUREN DER ACHTEN AUSFUHRUNGSFORM 
Fig. 34 veranschaulicht ein Muster eines Steuerflusses in einem dynamischen tJbersetzungssystem mit einem Ver- 
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zweigungsprofilierer genl^Kiner achtcn Ausluhrungsfonn der vorliegenden I^^^ng. 

• PHI ATT J JHRTC BESCHREIBUNG DER ACHTEN AUSFUHRUNGSFORM 

s . Wic im Dokumen! 'Verzweigungsprotokollierer fur die dynamischc Ubersetzung' heschrieben, profiliert das dynami- 
schc Ubersetzungssystem die Verzweigungsinsiruklionen des Origin alprogramms, wahrend sie inlerpreliert werden, uni 
zu besUmmen, welche Instruktionen haufig ausgefuhrt werden und welche nichi. Der Verzweigungsprotokollierer profi- 
liert nur Verzweigungsinstruktionen und verlaBt sich auf die Annahme, daB alle haufig ausgefuhrten Instrukrioneh durch 
haufig ausgeruhrle Verzweigungen erreichl werden. In einigen Fallen macht der dynainische Obersetzer selbst diese An- 

id nahine unwahr, da die Steuerung von den ubersetzten Instruktionen zuriick zu den interpretierten Instruktionen flieBu, 
ohne daB eine profilierte Verzweigung ausgefuhrt wird. Der Ubersetzer kann diese Falle idenufizieren, und er schafft spe- 
zielle ubersetzte Instruktionen, die diesen SteuerfluB profilieren als ware er eine Verzweigung. 

Fig. 34 veranschaulicht, wie die Steuerung von interpretierten Tnstruktionen zu ubersetzten Instruktionen und zuriick 
flieBL. Wo iminer die Steuerung einen Ausgang aus ubersetzten Instruktionen vornimmt, stellt der Ubersetzer sicher, daB 

15 der Ausgang profiliert wird als ware er eine Verzweigungsinstruktion. Es gibt einige Falle, in denen die Steuerung von 
ubersetzten zu interpretierten Instruktionen flieBt. 

lirstens gibt es Verzweigungen zu nichl-festgelegten Zielen. Der Ubersetzer weiB nicht, welche Instruktion nach der 
Ver/.weigung ausgefuhrt wird, daher kann er diese Instruktion nichi in dieselbe Ubersetzungseinheit kombinieren wie die 
Vcr/.weigung. Statt dessen schafft er einen Ausgang aus dem ubersetzten Code zuriick zum interpretierten Code.- 

>o Xweitens gibt es Instruktionen, die aufgrund von Seitenfehlern wahrend der Ubersetzung nicht gelesen werden kon- 
nen. Wie im Dokument 'Seitenfehlerbehebung fur die dynamische IJbersetzung' beschrieben, ignoriert der IJbdrsetzer 
Blocke von Instruktionen, die aufgrund eines Seitenfehlers nicht gelesen werden konnen. Daher muB das ubersetzte Pro- 
graniiii zu interpretierten Instruktionen zuruckspringen, wenn es diese Blocke erreicht. 

Drittens werden einige Instrukuonen selten ausgefuhrt, wahrend die Ubersetzung vorgenommen wird. Sie werden 
nicht ubersetzt, da sie selten ausgefuhrt wurden, wie im Dokument TBlockwahlschwelle fiir die dynamische Ubersetzung' 
beschrieben. Sie konnen jedoch in der Zukunfl haufiger ausgefuhrt werden, daher muB der Ubersetzer Ausgange zu die- 
sen Instruktionen aufzeichncn. Dieses Mcrkmal crmoglicht es dem dynamischen Ubcrsctzungssystcm, sich an die Andc- 
rung von Ausfiihrungsmustern anzupassen, welche die Verteilung haufig ausgefuhrter Instruktionen verandern. 

Du die Ausfange aus dem ubersetzten Code aufgezeichnet werden, werden mehr Instruktionen ubersetzt. Dies erhoht 

M) die C liance, daB eine ubersetzte Version einer Instruktion exisueren wird. Nachdem das dynamische Ubersetzungssystem 
cine lange Zeit laufen gelassen wird, verursachen daher die meisten der Ausgange aus einer ubersetzten Hnheit einen 
Sprung zu einer anderen ubersetzten Einheit anstelle eines Sprungs zuriick zum interpretierten Code. Dies hat einen di- 
rcklcn Vorteil durch die oftere Verwendung der schnelleren ubersetzten Instruktionen und einen indirekten \forteil durch 
i lie Ausfulirung der Verzweigungsprotokpmerinstruktionen nicht so oft. 

:?s 

BESONDERE OBJEKTE DER ACHTEN AUSFUHRUNGSFORM 

Die achte Ausfuhrungsform der vorliegenden Erfindung ist auf ein Verfahren gerichtet, um sicherzustellen, daB haufig 
uusgcT unite Instruktionen ubersetzt werden, auch wenn sie nicht durch irgendwelche profilierte Verzweigungen erreicht 
40 werden. indem die mdglichen Ausgange aus ubersetzten Instruktionseinheiten profiliert werden. 

ZUSAMMENFASSUNG DER ACHTEN AUSFUHRUNGSFORM 

Ein dynamisches Ubersetzungssystem muB alle haufig ausgefuhrten Instruktionen lokalisieren und ubersetzen, was 
45 durch Profmerverzweigungsinstruktionen erzielt werden kann. Die Ubersetzung von Instruktionen wird jedoch Pfade zu 
Instruktionen schaffen, die keine profilierten Verzweigungen enthalten. Daher wird die ProfiUerung erweitert, um die 
Ausgange aus ubersetzten Instruktionen zu enthalten. Die Erfindung ist ein Verfahren, um sicherzustellen, daB haufig 
ausgefuhrte Instruktionen ubersetzt werden, auch wenn sie nicht durch irgendwelche profilierte Verzweigungen erreicht 
werden, indem die moglichen Ausgange aus ubersetzten Instruktionseinheiten profiliert werden. 

50 

NEUNTE AUSFUHRUNGSFORM DER VORLIEGENDEN ERFINDUNG 

BIX)CKWAHLSCHWELLE FUR DIE DYNAMISCHE UBERSETZUNG 

55 KURZFASSUNG DER NEUNTEN AUSFUHRUNGSFORM 

Die dynamische Ubersetzung ist ein Akt der Ubersetzung eines Computerprogramms in einer Maschinensprache in 
eine andere Maschinensprache, wahrend das Programm lauft. Der dynamische Ubersetzer sollte alle der haufig ausge- 
fuhrten Teile des Quellenprogramms ubersetzen und alle der selten ausgefuhrten Teile ignorieren. Um dies zu erzielen, 
60 profiliert das Ubersetzungssystem Verzweigungsinstruktionen und ubersetzt jene Instruktionen nicht, deren Ausfuh- 
rungswahrscheinlichkeit unter einer spezifizierten Schwelle liegt. 

BESCHREIBUNG VON FIGUREN DER NEUNTEN AUSFUHRUNGSFORM 

65 Fig. 35 veranschaulicht, wie der dynamische Ubersetzer Verzweigungsprofilinformarionen verwendet, um die Aus- 
fuhrungswahrscheinlichkeit eines Basisblocks zu berechnen, gemaB einer neunten Ausfuhrungsform der vorliegenden 
Erfindung. 
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DUTAILLmi^»ESCHREmUNG DER NEUNTEN AUSEDflR^KFORM 



Der Zweck eines dynamischen Ubcrscizers ist, die allgemeine Ausfuhrungsgeschwindigkcit eines Computerpro- 
gramms zu verbessern, indem cr es aus seinen urspriinglichen Quellen-Sprachinslruktionen in eflizienicre Ziel-Sprach- 
inslruktioncn ubersetzt. Der Vorteil der dynaniisehen Uberselzung wird durch den Vergleich der Gcsamtzeit fur die Aus- 5 
fuhrung des Originalprogramnis mil der fiir die Uberselzung des Programms erfordcrlichen Zeit plus der Zeit fiir die 
Ausfuhrung des ubersetzten Programms gemessen. Die zur Ubersetzung irgendeines Teils des Programms erforderlichc 
Zeit ist ungefahr konstant, daher wird der Vorteil der Ubersetzung eines Teils hauptsachlich durch die Anzahl von Malen, 
die dieser Teil verwendet wird, bestimmt . Haufig ausgefuhrte Instruktionen sind es Wert, ubersetzt zu werden, selten aus- 
gefuhrte Inst ruktionen si nd esjedoch nicht Wert, ubersetzt zu werden. to 

Zur Messung der Frequenz verschiedener Instruktionen kann ein dynamisches Ubersctzungssyslem Verzweigungsin- 
siruktionen profilieren. Unter Verwendung dieser Profilin fori nationen kann es eine haufig ausgefuhrte Instruktion wahlen 
u nd an diesem Punkt die Ubersetzung beginnen. Nach der anfanglichen Tnsrruktion versucht der Ubersetzer so viele hau- 
Iili ausgefuhrte Nachfolgerinstruktionen zu lesen wie moglich, ohne die seltenen Nachfolger zu lesen. Die Blockwahl- 
schwelle wird verwendet, urn zu beslimmen, ob ein Nachfolger haufig oder selten ausgefiihrt wird. 15 

Der dynamische Ubersetzer best Instruktionen in Einheiten, die Basisblocke genannt werden. In einem Basisbiock 
ucrden alle der Instruktionen die gleiche Anzahl von Malen ausgefiihrt, daher werden entweder alle haufig ausgefiihrt 
• »dcr alle selten ausgefiihrt. 

Der dynamische Ubersetzer verwendet Profilinformationen aus Verzweigungs instruktionen, um zu bestimmen, ob ein 
!i:isisblock haufig oder selten ausgefiihrt wird. Dieser ProzeB ist in Fig. 35 gezeigL Der Ubersetzer berechnet die Wahr- 20 
schcinlichkeit, daB ein Ausfuhrungspfad von der ersten ubersetzten Instruktion zu einem gegebenen Basisbiock einge- 
schlugen wird. Der erste Basisbiock erhalt eine Ausfiihrungswahrscheinlichkeit von 100%, da er die erste Ins/riiktion 
cm huh. Wenn der aktuelle Block nur einen Nachfolger hat, dann hat der Nachfolger dieselbe Ausfiihrungswahrschein- 
tichkcit wie der aktuelle Block. Wenn der aktuelle Block in einer bedingten Verzweigung endet, dann wird die Wahr- 
scheinlichkeil des aktuellen Blocks zwischen den beiden Nachfolgern gemaB den Verzweigungsprofilinfoniiationen ge- 25 
tcill. Wenn die Ausftihrungswahrscheinlichkeil des aktuellen Blocks beispielsweise 50% war, und er in einer Verzwei- 
irtinsisinsiruktion endet, die 40 Mai ausgefiihrt und 10 Mai cingcschlagcn wurdc, dann ware die Wahrschcinlichkcit des 
Ycr/.woigung-eingeschlagen-Nachfolgers (50% - 25% = 12,5%), und die Wahrscheinlichkeit des Fehlschlag-Nachfol- 
-ers ware (50% ■ 75% = 37,5%). 

Kine variable Schwelle, die Block wahlschwelle genannt wird, wird zum Auswahlen haufig ausgefuhrter Blocke ver- 30 
wctuicl. Wenn die Ausfuhrungswahrscheinhchkeit eines Blocks groBer als die oder gleich der Schwelle ist, dann wird 
dieser Block als haufig ausgefiihrt angesehen, und er wird ubersetzt. Wenn die Ausfuhrungswahrscheinlichkeit unter der 
Schwelle liegt, dann wird der Block als selten ausgefiihrt angesehen, und er wird nicht ubersetzt. 

I -inc wichtige Eigenschaft dieses Blockwahlverfahrens ist, daB der Satz gewahlter Blocke verbunden ist. Es gibt kom- 
pli/.iertere Wege der Berechnung der Ausfuhrungswahrscheinlichkeit, wie das Addieren der Wahrscheinlichkeiten aus 35 
ullcn Vorlaufern. Dies kann jedoch zu nicht-zusanunen-hangenden Satzen von Blocken fuhren. Es ist moglich, nichtzu- 
saninienhangende Satze von Blocken zu ubersetzen, aber es gibt mehr Moglichkeiten zur Optimierung des ubersetzten 
(\xtes, wenn er vollig zusammenhangend ist. 

BESONDERE OBJEKTE DER NEUNTEN AUSFOHRUNGSFORM 40 

Die ncuntc Ausfiihrungsfonii der vorliegenden Erfindung ist auf ein Verfaliren zur Verbesserung der Effizienz der dy- 
numischen Ubersetzung gerichiel, indem Blocke haufig ausgefuhrter Instruktionen zur Ubersetzung gewahlt und Blocke 
scllcn ausgefuhrter Instruktionen ignoriert werden, wobei eine Schwellenausfuhrungswahrscheinlichkeit zur Trennung 
ilcr haufig ausgefuhrtcn Blocke von selten ausgefuhrten verwendet wird. 45 

ZUSAMMENFASSUNG DER NEUNTEN AUSFUHRUNGSFORJVI 

Hin dynamisches tjherscizungssystem muB kostenproportional zur Anzahl iibersetzter Instruktionen und nutzenpro- 
porlional zur Anzahl von Malen sein, die eine iibersetzte Instruktion ausgefiihrt wird. Daher ist es am effizientesten, nur 50 
haufig ausgefuhrte Instruktionen zu ubersetzen, und die selten ausgefuhrten zu ignorieren. Die Erfindung ist ein \ferfah- 
ren zur Verbesserung der KtTizicnz der dynamischen Ubersetzung, indem Blocke haufig ausgefuhrter Instruktionen zur 
Ubersetzung gewahlt und BJocke selten ausgefuhrter Instruktionen ignoriert werden, wobei eine Schwellenausfuhrungs- 
wahrscheinlichkeit zur Trennung der haufig ausgefuhrten Blocke von selten ausgefuhrten verwendet wird. 

Obwohl einige bcvorzugic Ausfuhrungsformen der vorliegenden Erfindung erlautert und beschrieben wurden, ist es 55 
fur Fachleute klar, daB Anderungen in diesen Austuhrungsformen vorgenommen werden konnen, ohne von den Prinzi- 
pien und dem Grundgedanken der Erfindung abzuweichen, deren Umfang in den AnsprUchen und ihren Aquivalenten 
definiert ist. 

Patenmnspriiche 60 

1 . Computerarchiiektur-Emulationssystern, welches eine Quellen-Computerarchitektur auf einer Ziel-Computerar- 
chi tektur emu lien , mi t : 

einer Interpretierereinrichtung zum individueiien Ubersetzen eines Quelien-Objektcodes in einen entsprechenden 
ubersetzten Objekicode und zum Bestimmen einer Anzahl von AusfUhrungen von \ferzweigungsinstrukuonen im 65 
Quellen-Objektcode; und 

einer Kompiiierereinrichtung zum Gruppieren von Instruktionen des Quelien-Objektcodes in ein Segment, wenn 
eine Anzahl von Ausfuhrungen einer entsprechenden Verzweigungsinstruktion eine Schwellenanzahl uberschreitet, 
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und zum dynaniischePSompilieren des Segments. 

2. Coniputerarchitekiur-Emulationssystem nach Anspruch 1, bei welchem Verzweigungs-Objeklcode-Instruktio- 
nen, die Segment en entsprechen, welche nicht kompilieri sind, im Speicher gespeicherl werden. 

3. Computerarchilekiur-Emulationssystem nach Anspruch 2, bei welchem Segmente, die Verzweigungs-Objekt- 
code-Instruktionen entsprechen, welche die Schwellenanzahl nicht uberschritten haben, nicht kompiliert werden. 

4. Computerarchitektur-Emulationssystern nach Anspruch 1, bei welchem Segment e, die Verzweigungs-Objekt- 
code-Instruktionen entsprechen, welche Segmenten entsprechen, die nicht kompiliert sind, im Speicher gespeicherl 
werden, wahrend die Interpret ierereinrichtung die ubersetzten Objektcode-Instruktionen ausfuhrt. 

5. Computerarchitektur-Emulationssystem nach Anspruch 1, bei welchem die Interpretierereinrichtung und die 
Kompilierereinrichtung Aufgaben sind, die gleichzeitig in einem Mehraufgaben-Betriebssystem in Echtzeit operie- 
ren. 

6. Computerarchitektur-Emulationssysteni nach Anspruch 1, ferner nut: 

einer Verzweigungsprotokollierereinrichtung zum Speichern von Verzweigungsprofilin format ionen der Verzwei- 
gungsinstruklionen, die von der Interpretierereinrichtung beslimmt werden. 

7. Conipulerarchitektur-Emulationssystem nach Anspruch 6, bei welchem 

die Verzweigungsprofilinforniationen eine Verzweigungsadresse, einen Verzweigungsnachfolger, einen Nicht- Ver- 
zweigungsnachfolger, eine Verzweigungsausfuhrungszahlung und eine Verzweigung-eingeschlagen-Zahlung ent- 
halten, und 

die Verzweigungsprofilinfqrmationen von der Interpretierereinrichtung wahrend der Verzweigungsinstruktions- 
emulation protokolliert werden. 

8. C^omputerarchitektur-Emulaiionssysteni nach Anspruch 1, ferner mit: 

einer Einrichtung zum Plazieren einer Codeflagge nach Verzweigungsinstruktionen, die einen Sprung in iibersetz- 
bare Instruktionen oder aus diesen ausfuhren; und 

einer Einrichtung zum Priifen, ob Nachfolgerinstruktionen der entsprechenden Verzweigungsinstruktionen uber- 
setzbar sind oder nicht, indern auf die entsprechende Codeflagge bezuggenommen wird. 

9. ComputerarchilekLur-Eiiiulalionssysteiii nach Anspruch 1, ferner mil: 

cincr Einrichtung zum Iniliicrcn cincr Vcrzwcigungsinstruktion, wenn cine Anzahl von Ausfiihrungcn cincr Nach- 
folgerinstruktion der Verzweigungsinstruktion einen Schwelienwert ubersteigt. 

10. Computerarchitektur-Emulationssystem nach Anspruch 1, ferner mit: 

einer Einrichtung zum Kommunizieren zwischen der Interpretierereinrichtung und der Kompilierereinrichtung, 
wahrend die Interpretierereinrichtung die Emulation des Quellencodes fortsetzt, um die Ubersetzung von Segmen- 
ten, die haufig verzweigten Instruktionen entsprechen, zu initiieren. 

11. Computerarchitektur-Emulationssystem nach Anspruch 1, ferner mit: 

einer Einrichtung zum Steuern einer Kompilierungsrate von zu kompilierenden Segmenten durch die Erhohung der 
Schwellenanzahl, wenn eine Wartescblage zum Speichern der zu ubersetzenden Segmente eine vorherbestimmte 
Kapazitat erreicht. 

12. Computerarchitektur-Emulationssystem nach Anspruch 1, bei welchem die Kompilierereinrichtung ein opti- 
miertes Objekt erzeugt, wahrend jede Instruktion, die sich im Speicher befindet, der Reihe nach verfolgt wird, in- 
dern ein Profil verwendet wird, das der Adresse entspricht, an der die Kompilierung gestartet wurde. 

13. Computerarchitektur-Emulationssystem nach Anspruch 12, bei welchem die Kompilierereinrichtung einen 
Block bei der Detektion eines Seitenfehlers nicht kompiliert, so daB, wenn ein Block einen Seitenfehler verursacht, 
die Kompiuerereinrichtung ein Objekt produziert, um Verzweigungsinformationen in der Verzweigungsprotokol- 
hereinrichtung zu protokollieren. 

14. Computerarchitektur-Emulationssystem nach Anspruch 13, bei welchem, wenn ein Instruktionsausfuhrungs- 
prozeB in bezug auf eine vorherbestimmte Rate nicht rechtzeitig ausfuhrt, die Kompilierereinrichtung die Ausfuh- 
rung unter Verwendung eines Profils verfolgt, priift, ob eine Verzweigungszahlung unter einer vorherbestimniten 
Anzahl liegt, und ein Objekt produziert, um Verzweigungsinformationen zu protokollieren. 

15. Computerarchitektur-Emulationssystem nach Anspruch 1, ferner mit: 

einer VerzweigungsprotokoUiereinrichtung zum Speichern von Profilinformationen der Verzweigungsinstruktionen 
im Quellen-Objektcode, der die Anzahl von Ausfuhrungen enthalt, wobei die Verzweigungsprotokolhereinrichtung 
einen Cache zum Speichern von Profilinformationen haufig ausgefuhrter Verzweigungsinstruktionen und ein Ver- 
zweigungsprotokoll zum Speichem von Profilinformationen weniger haufig ausgefuhrter Verzweigungsinstruktio- 
nen enthalt. 

16. Computerarchitektur-Emulationssystem nach Anspruch 15, bei welchem die Profilinformationen im Cache 
durch das Kombinieren von Verzweigungsadresseninformationen und Verzweigungszielinformationen organisiert 
werden. 

17. Computerarchitektur-Emulationssystem nach Anspruch 16, bei welchem die im Cache organisienen Profilin- 
formationen in einer Vielzahl von Gruppen in absteigender Reihenfolge des Eintrags in die Gruppe gespeicherl wer- 
den. 

18. Computerarchitektur-Emulationssystem nach Anspruch 1, bei welchem jede Verzweigungsinstruktion ein 
Startparameter ist, wobei die KompUierereinrichtung ferner enthalt: 

einen Blockwahler, der ein Segment des zu kompilierenden Quellen-Objektcodes auf der Basis des Startparameters 
und der Profilinformationen der Verzweigung auswahlt, 

eine Blockaufbaueinheit, die das Segment in eine lineare Liste von Instruktionen abflacht, und 

eine optimierende Codegenerierungseinheit, welche die tatsachhche Kompilierung von Originalinstruktionen in 

iibersetzte Codesegmentinstruktionen durchfiihrt. 

19. Computerarchitektur-Emulationssystem nach Anspruch 18, bei welchem der Blockwahler einen SteuerfluBgra- 
phen schafft, der die zu kompilierenden Originalinstruktionen beschreibt, und den SieuerfluBgraphen zur Biockauf- 
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niulalionssysieni, welches eine Qucllen-Compuierarchiiekiui 



baucinheil weilerrcichl. 

20. Conipuicrarchiiektur-EiiiuTalionssysieni, welches eine Qucllen-Compuierarchiiekiur auf einem Ziel-Compu- 
terarchitektursysiem emu lien, mil: 
einer Vielzahl von Inlerpretierereinrichlungen zuni individuellen ubersetzen eines Quellen-Objeklcodes in einen 
enlsprechenden Ubersetzlen Onjektcodc. wobei jede der Vielzahl von Inlerprelierereinrichlungen Quell en-Objekl- 5 
code-Verzweigungsinfonualionen in Echlzeit profiliert, wahrend sie uberselzte Objektcode-Inslruktionen ausfuhrt; 
und 

einer Kompilierereinrichlung zum Gruppieren von Quellen-Objeklcode-Instruklionen von irgendeiner der Vielzahl 
von Inlerpretierereinrichtungcn in Segmente aul der Basis entsprechender Verzweigungsinstruktionen ini Quellen- 
Objeklcode und zum dynamischen Kornpilieren der Segmente des Quellen-Objeki codes, wenn die entsprechende 10 
Verzweigungsinstruktion groBerist als eine Schwellenanzahl. 

21. Computerarchitektur-Emulationssyslem nach Anspruch 20, bei welchem jede der Vielzahl von Interprctierer- 
einrichtungen die Ver7.weigungs-Objektcode-Tnslruktionen profilien und die Ver/.weigungs-Objektcode-Tnstruktio- 
nen speichert. welche die Schwellenanzahl nichl uberschritten haben, indem ein Verzweigungsprotokollierer aufge- 
rufen wird. 15 

22. Computerarchilektur-Emulationssystem, welches eine Quellen-Compulerarchitektur auf einem Ziel-Compu- 
terarchilektursystem emuiierl, mil: 

einer Interpretierereinrichtung zuni individuellen Ubersetzen eines Quellen-Objektcodes in einen ent spree henden 
iibersetzten Objekrcode, wobei die Interpretierereinrichtung Verzweigungsinstruktionen des Quellen-Objektcodes 
durch das Speichem einer Anzahl von Ausfuhrungen fur jede Verzweigungsinstruktion und Vergleichen der Anzahl 20 
von Ausfuhrungen mil einer Schwellenanzahl profiliert, so daB Verzweigungsinstruktionen, welche die Schwellen- 
anzahl uberschreiten, Startparameter sind; und 

einer Kompilierereinrichlung zum Gruppieren der Quellen-Objektcode-Instruktionen in Segmente auf der Basis der 
Startparameter und dynamischen Kornpilieren der Segmente des Quellen-Objeklcodes wahrend der Ubersetzung 
und Profilierung durch die Interpretierereinrichtung. 25 

23. Compulerarchilektur-EmulaLionssystem nach Anspruch 22, bei welchem 

jedes Segment Instruktioncn enthalt, die aus der Optimicrung des Qucllcn-Objcktcodcs auf der Basis cincs cntsprc- 

chenden Startparameters resultieren, und 

jedes Segment als Einheit installiert und deinstalliert wird. 

24. Computerarchilektur-Emulationssystem nach Anspruch 23, bei welchem Verzweigungs-Objektcode-Instruk- 30 
tionen, die Segmenien entsprechen, welche nicht kompiliert sind, im Speicher gespeichert werden, wahrend Seg- 
mente, die Verzweigungs-Objektcode-Instruktionen entsprechen, welche die Schwellenanzahl nicht uberschritten 
haberi, nicht kompiliert werden. 

25. Computerarchitektur-Emulationssystem nach Anspruch 23, ferner mit: 

einer Verzweigungsprotokollierereinrichtung zum Speichern von Verzweigungsprofilinformationen der Verzwei- 35 
gungsinstruktionen, die von der Interpretierereinrichtung bestimmt werden, wobei die Verzweigungsprofibnforma- 
tionen eine Verzweigungsadresse, einen Verzweigungsnachfolger, einen Nicht- Verzweigungsnachfolger, eine Ver- 
zweigungsausfuhrungszahlung und eine Verzweigung-eingeschlagen-Zahlung enthalten, und die Verzweigungspro- 
filinformationen von der Interpretierereinrichtung wahrend der Verzweigungsinstruktionsemulation protokolliert 
werden. 40 

26. Computerarchiiektur-Emulationssystem nach Anspruch 23, ferner mit: 

einer Einrichtung zum Plazieren einer Codeflagge nach Verzweigungsinstruktionen, die einen Sprung in ubersetz- 
bare Instruktionen oder aus diesen ausfuhren; und 

einer Einrichtung zum Priifen, ob Nachfolgerinstruktionen der entsprechenden Verzweigungsinstruktionen uber- 
setzbar sind oder nicht, indem auf die entsprechende Codeflagge bezuggenornmen wird. 45 

27. Computerarchitektur-Emulationssystem nach Anspruch 23, ferner mit: 

einer Einrichtung zum Initiieren einer Verzweigungsinstruktion, wenn eine Anzahl von Ausfuhrungen einer Nach- 
folgerinstruktion der Verzweigungsinstruktion einen Schwellenwert iibersteigt. 

28. Computerarchiiektur-Emulationssystem nach Anspruch 23, ferner mit: 

einer Einrichtung zum Steuern einer Kompilierungsrate von zu kompilierenden Segmenten durch die Erhohung der 50 
Schwellenanzahl, wenn eine Warteschlage zum Speichern der zu ubersetzenden Segmente eine vorherbestimmte 
Kapazitat erreicht. 

29. Computerarchitektur-Emulations system nach Anspruch 23, bei welchem, wenn ein Instruktionsausfuhrungs- 
prozeB in bezug auf eine vorherbestimmte Rate nicht rechtzeitig ausfuhrt, die Kompilierereinrichtung die Ausfuh- 
rung unter Verwendung eines Profils verfolgt, priift, ob eine Verzwei gungszahlung unter einer vorherbestimmten 55 
Anzahl liegt, und ein Objekt produziert, um Verzweigungsinformationen wie den Seitenfehler zu protokollieren. 

30. Computerarchitektur-Emulationssystem nach Anspruch 23, ferner mit: 

einer Verzweigungsprotokolliereinrichtung zum Speichern von Profilinformationen der Verzweigungsinstruktionen 
im Quellen-Objektcode, der die Anzahl von Ausfuhrungen enthalt, 

wobei die Verzweigungsprotokolliereinrichtung einen Cache zum Speichern von Profilinformationen haufig ausge- 60 
fuhrter Verzweigungsinstruktionen und ein Verzweigungsprotokoll zum Speichern von Profilinformationen weni- 
ger haufig ausgefuhrter Verzweigungsinstruktionen enthalt, 

wobei die Profilinformationen im Cache durch das Kombinieren von Verzweigungsadresseninformationen und Ver- 
zweigungszielinformationen organisiert werden, und die im Cache organisierten Profilinfonnationen in einer Viel- 
zahl von Gruppen in absteigender Reihenfolge des Eintrags in die Gruppe gespeichert werden. 65 

31. Computerarchitektur-Emulations system nach Anspruch 23, bei welchem die Kompilierereinrichtung ferner 
enthalt: 

einen Blockwahler, der ein Segment des zu kompilierenden Quellen-Objektcodes auf der Basis des Startparameters 
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nnaiionen der Verzweieune auswahlt, wobci der Block^Pic 



v) 



40 



45 



50 



55 



60 



65 



unci der ProfilinfoniTSfTbnen der Vcrzweigung auswahll, wobci der Block^BTer einen SteuerfluBgraphen schafft, 
der die zu kompilierenden Originalinstruklionen beschreibi; 

eine Blockaufbaueinheit, die den SteuerfluBgraphen in eine lineare Lisle von Instrukiionen abflachi, und 

eine optimierende Codegenerierungseinheit, welche die lalsachliche Kompilierung von Originalinstruklionen in 

iihersetzte Codesegnientinstniktionen durchfiihn. 

32. Mehrdulgaben-Conipulerarchitckiur-Einulationssysiein, welches eine Qucllen-Compulerarchitektur auf einer 
Mehraufgaben-Ziel-Compulerarchilektur emuliert, mil: 

einer Interpretiereraufgabe zum individuellen Ubersetzen eines Quellen-Objektcodes in einen entsprechenden uber- 
setzten Objektcode und zum Bestimmen einer Anzahl von Ausluhrungen von Verzweigungsinstruktionen im Qucl- 
len-Objekicode; und 

einer Kompiliereraufgabe, die mil deni Interpretierer auf der Mehraufgaben-Ziel-Computerarchitektur operiert, 
zum Gruppieren von Instruktionen des Quellen-Objektcodes in ein Segment., wenn eine Anzahl von Ausfiihrungen 
einer entsprechenden Verzweigungsinstruktion eine Sen well en anzahl uberschreilet, und zum dynamischen Kompi- 
lieren des Segments. 

33. Meliraufgaben-Computerarchitektur-Emulationssystem nach Anspruch 32, welches Mehraufgaben-Computer- 
architektur-Emulationssystem ein dynamisches Ubersetzungssystem ist, wobei das Mehraufgaben-Computerarchi- 
tektur-Emulationssystem ferner umfaBt: 

cine Software-Ruckkopplungseinrichtung zum Ausgleichen einer Rate von Kompilierungsanforderungen, die von 
der Interpretiereraufgabe gesendet werden, und der Rate von Kompilierungen, die von der Kompiliereraufgabe 
vollendet werden, ohne daB es der Kompiliereraufgabe gestattet wird, untalig zu werden, indem die Schwellenan- 
zahl variiert wird. 

34. Mehraufgaben-Computerarchitektur-Emulationssystem nach Anspruch 33, femer mit: 

einer Warteschlange zum Speichern von Segmenten, die von der Kompiliereraufgabe zu kompilieren sind, wobei 
die Schwellenanzahl mit einer Mindestschwellen anzahl verglichen wird, um die Kompiliereraufgabe ein- oder aus 
zu schallen. 
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